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1.  INTRODUCTION 


A.  BACKGROUND 

1.  History  of  Ballistic  Missile  Defense 

Ballistic  missiles  were  first  used  by  Nazi  Germany  against  Antwerp  and  London. 
At  that-dme,  ballistic  missile  defense  was  technologically  limited  to  air-burst  artillery  fire 
to  deflect  or  destroy  incoming  missiles.  During  the  Cold  War  period,  the  superpowers 
kept  each  other  in  check  by  refining  the  ballistic  missile  concept  and  building  large 
numbers  of  inter-continental  ballistic  missiles  (ICBMs).  Their  defenses  consisted  of 
nuclear  air-burst  interceptors,  with  reliance  on  the  concept  of  Mutually  Assured 
Destruction.  In  1972  the  United  States  and  the  former  Soviet  Union  signed  the  Anti- 
Ballistic  Missile  (ABM)  Treaty.  This  treaty  placed  specific  limitations  on  the  size, 
number,  and  speed  of  each  nation’s  defensive  capability.  Today,  missile  defense  is 
segmented  into  two  broad  categories.  Strategic  systems  defend  a  continental-size  area 
from  inter-continental  or  sea  launched  ballistic  missile  attack,  and  theater  systems  defend 
a  smaller  region  from  ballistic  missile  attack.  The  ABM  Treaty  places  most  of  its 
limitations  on  strategic  systems. 

Development  of  a  United  States  strategic  missile  defense  system  has  been  an 
intermittent  project  for  several  decades.  Portions  of  the  technologies  required  for  this 
military  capability  are  available,  but  an  integrated  system  does  not  now  exist.  Our  current 
national  strategy  gives  priority  to  developing  and  fielding  theater  missile  defense  (TMD) 
systems,  while  keeping  the  strategic  systems  in  a  Technology  Readiness  Program.  This 


1 


strategy  places  emphasis  on  the  greatest  threat.  As  the  threat  to  the  United  States  grows, 
the  National  Missile  Defense  (NMD)  system  can  be  accelerated  from  a  Technology 
Readiness  Program.  This  strategy  permits  NMD  fielding  if  needed,  and  allows  the 
opportunity  to  leverage-in  mature  TMD  technologies.  This  thesis  is  a  case  study  of  the 
acquisition  strategy  for  the  Theater  High  Altitude  Area  Defense  (THAAD)  system. 
THAAD  is  a  high  priority  TMD  system  currently  in  development. 

2.  Ballistic  Missile  Threat 

In  the  post-Cold  War  period,  the  threat  of  a  large  scale  ICBM  attack  against  the 
United  States  is  practically  non-existent.  On  the  other  hand,  the  medium  range  tactical 
ballistic  missile  (TBM)  threat  is  diversifying,  growing  faster  than  ever,  and  can  carry 
weapons  of  mass  destraction.  Today,  more  than  30  types  of  TBMs  exist.  Nineteen 
nations  possess  missiles  that  can  carry  a  payload  of  1,000  kilograms  to  a  range  greater 
than  300  kilometers  [Ref.  1:  p.  34].  A  growing  number  of  countries  are  working  on 
missiles  with  ranges  greater  than  1,000  kilometers. 

The  PATRIOT  missile  system's  role  during  Operation  Desert  Storm  brought  some 
public  attention  to  TBMs  and  our  severely  limited  defensive  capability.  During  the  Gulf 
War,  once  Iraq  launched  a  TBM,  the  PATRIOT  PAC-2  (PATRIOT  Advanced  Capability- 
2)  missile  was  the  only  defense.  The  allied  nations  deployed  almost  every  PATRIOT  fire 
unit  in  the  world  to  the  region,  but  PAC-2  missiles  provided  only  limited  coverage  for  top 
priority  political  assets.  Tactical  and  strategic  assets  were  virtually  unprotected. 

TBMs  are  a  threat  to  our  forward  deployed  forces  and  the  homelands  of  many  of 
our  allies.  Given  the  current  growth  rate,  a  limited  ICBM  threat  to  the  United  States 
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homeland  will  reappear.  The  question,  currently  receiving  much  political  debate,  is  how 
soon  this  threat  will  reappear? 

3.  Legislative  Mandate 

In  response  to  the  growing  threat.  Congress  passed  the  Missile  Defense  Act  of 
1991 .  This  legislation  required  abrupt  new  steps  toward  deployment  of  NMD  and  TMD 
systems.  The  Act,  signed  into  law  December  5, 1991,  required  the  Secretary  of  Defense 
(SEC  DEF)  to  have  an  operationally  effective  TMD  capability  by  1996.  The  law  gave 
the  SEC  DEF  180  days  to  present  a  Department  of  Defense  (DOD)  plan  to  meet  the  1996 
deployment  deadline.  [Ref.  2] 

Ballistic  Missile  Defense  Organization  (BMDO),  formerly  Strategic  Defense 
Initiative  Organization,  is  the  DOD  organization  responsible  for  coordinating 
development  of  missile  defense  capabilities.  In  response  to  the  180  day  mandate,  BMDO 
planners  reviewed  the  ballistic  missile  threat  compared  to  our  existing  and  future  missile 
defense  technologies.  Because  the  ABM  Treaty  was  a  constraint  on  available  options,  all 
options  were  classified  as  treaty  compliant  or  treaty  non-compliant. 

4.  Options  Available 

One  promising  TMD  option  was  THAAD.  It  appeared  that  THAAD  would  be 
effective  against  the  growing  threat  and  be  treaty  compliant.  Additionally,  THAAD  could 
demonstrate  a  significant  technology  maturity  to  the  NMD  Technology  Readiness 
Program.  Figure  1  is  the  author’s  depiction  of  the  situation  BMDO  faced  in  1991.  Threat 
capability  is  graphed  in  the  background.  It  was  ahead  of  our  existing  TMD  capability, 
and  it  was  growing  at  a  steady  pace.  Enhancements  to 
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Figure  1.  THAAD  Acquisition  Strategy  -  Traditional  Approach 


PATRIOT  (i.e.,  PAC-3)  would  bring  some  defense  against  the  threat,  but  a  new 
generation  weapon  system  was  required  to  outpace  the  threat.  Development  of  THAAD 
would  provide  a  foundation  for  our  capability  to  outpace  the  threat  well  into  the  next 
century.  Under  a  traditional  acquisition  strategy,  the  Initial  Operational  Capability  (IOC) 
of  THAAD  would  be  at  least  ten  years  away.  This  time  frame  was  unacceptable  to 
BMDO  planners  because  it  would  not  provide  the  urgently  needed  TMD  capability  for 
our  forward  deployed  forces  and  many  of  our  allies. 

A  traditional  acquisition  strategy  could  not  meet  the  urgent  need  and  fulfill  the 
legislative  mandate.  Therefore,  BMDO  planners  conceived  the  User  Operational 
Evaluation  System  (UOES)  strategy  for  THAAD.  Figure  2  is  the  author’s  depiction  of 
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Figure  2.  THAAD  Acquisition  Strategy  -  User  Operational  Evaluation  System  Approach 


BMDO’s  innovative  approach  to  meet  the  threat.  This  aggressive  strategy  produces  an 
interim  operational  prototype,  which  may  be  used  in  a  variety  of  ways  to  enhance  the 
objective  system.  Additionally,  the  strategy  provides  for  the  prototype  system  to  be 
available  for  deployment  in  the  event  of  a  national  emergency.  This  aggressive  strategy 
was  a  direct  response  to  the  Congressional  mandate  to  rapidly  develop  a  TMD  capability. 
B.  OBJECXrVE 

The  objective  of  this  thesis  is  to  examine  UOES  as  an  innovative  acquisition 
strategy.  The  author  will  examine  trade-offs  made  within  the  program  among  cost, 
schedule,  and  performance.  From  this  examination,  lessons-leamed  will  be  identified  that 
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will  aid  acquisition  management  personnel  in  making  informed  decisions  about  selection 
of  a  UOES  acquisition  strategy  for  future  programs. 

C.  RESEARCH  QUESTIONS 

In  pursuit  of  the  objective  of  this  thesis,  the  primary  research  question  is:  What 
are  the  lessons  from  the  THAAD  program  that  will  be  helpful  to  other  acquisition 
managers  in  minimizing  cost,  schedule  and  performance  risk? 

The  subsidiary  research  questions  are: 

1.  What  are  the  specialized  requirements  that  drove  the  program  to  its 
operational  prototype  strategy? 

2.  What  are  the  key  THAAD  risks,  and  how  has  the  acquisition  strategy 
addressed  those  risks? 

3.  What  risks  have  been  increased  as  a  result  of  the  strategy? 

4.  What  advantages  and  disadvantages  should  acquisition  managers 
consider  before  including  an  operational  prototype  in  an  acquisition 
strategy? 

D.  SCOPE 

THAAD  is  in  the  final  year  of  a  four  year  demonstration  and  validation 
(DEM/VAL)  contract.  Flight  test  five  of  14  DEMA^AL  flight  tests  took  place  on  March 
22, 1996.  Final  data  analysis  of  this  test  is  still  pending.  Therefore,  this  thesis  is  based 
on  observations  prior  to  test  five.  Because  this  is  an  ongoing  program,  a  complete  study 
of  the  effectiveness  of  the  acquisition  strategy  is  not  yet  possible.  However,  an 
examination  of  the  decision  making  process  and  the  dynamics  in  the  acquisition 
environment  that  have  thus  far  influenced  the  THAAD  program  is  beneficial. 
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Analysis  is  of  the  THAAD  program  issues  only.  THAAD  will  be  a  major  element 
in  the  Active  Defense  pillar  of  Joint  Theater  Missile  Defense  (JTMD)  doctrine.  When 
relevant,  there  is  some  comparison  of  THAAD  issues  to  other  programs  facing  similar 
situations. 

E.  LITERATURE  REVIEW  AND  METHODOLOGY 

This  thesis  is  a  case  study  of  the  acquisition  strategy  used  in  the  THAAD 
program.  First,  there  is  a  background  review  of  DOD  risk  management;  this  is  followed 
by  a  review  of  some  current  uses  of  prototypes  in  systems  development.  Next,  the 
THAAD  system  and  its  innovative  acquisition  strategy  is  outlined.  This  background 
information  is  then  used  to  conduct  an  analysis  of  risk  management  issues  related  to  the 
acquisition  strategy. 

The  author  obtained  background  information  from  DOD  reports,  General 
Accounting  Office  reports,  professional  papers,  DOD  publications,  and  THAAD  program 
documents.  These  documents  were  found  through  research  in  the  Naval  Postgraduate 
School  Library  or  from  Defense  Logistics  Studies  Information  Exchange.  Much 
information  was  obtained  through  visits  to  the  THAAD  Project  Office  (TPO)  and  to  the 
THAAD  prime  contractor,  Lockheed  Martin  Missiles  and  Space  Company  (LMSC). 

F.  DEFINITIONS,  ACRONYMS,  AND  POLICY  CHANGES 

The  author  uses  standard  DOD  and  Army  definitions  for  acquisition  management 
and  missile  defense  terms.  Appendix  A  provides:  (1)  the  definition  of  terms  that  have  a 
designated  meaning  in  this  thesis,  (2)  a  consolidated  designation  of  the  acronyms. 
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Appendix  B  provides  a  summary  of  some  recent  trends  related  to  risk  management 
terminology. 

The  author  assumes  the  reader  is  generally  familiar  with  the  Department  of 
Defense  Acquisition  Management  Process.  This  document  is  based  on  terms  and  policies 
in  effect  in  1991  at  the  initiation  of  the  THAAD  program.  Table  1  cross  references  the  old 
and  new  terms  for  acquisition  phases  as  they  are  found  in  the  5000  Series  of  Department 
of  Defense  Instructions. 


Concept  Exploration  &  Definition 

Concept  Exploration 

Demonstration  &  Validation 

Program  Definition  &  Risk  Reduction 

Engineering  &  Manufacturing  Development 

Engineering  &  Manufacturing  Development 

Production  &  Deployment 

Production/Fielding,  Deployment,  and 
Operational  Support 

Operations  &  Support 

Table  1.  Cross  Reference  of  Old  and  New  Terms  used  for  Acquisition  Phases 
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n.  PROTOTYPING  AS  A  RISK  MANAGEMENT  STRATEGY  IN  THE 

ACQUISITION  PROCESS 


A.  PURPOSE 

An  acquisition  strategy  sets  a  course  for  a  program  to  follow  throughout  its  life- 
cycle.  A  PM  should  tailor  the  strategy  to  address  unique  risks  or  unknowns  of  the 
program.  A  strategy’s  goal  is  to  insure  a  program  delivers  a  useable,  supportable,  and 
reliable  product  within  acceptable  constraints  of  cost,  schedule,  and  performance.  This 
chapter  first  examines  how  DOD  acquisition  strategies  typically  approach  risk 
management.  Second,  it  overviews  some  current  methods  and  applications  of 
prototyping.  Finally,  this  chapter  reviews  some  advantages  and  disadvantages  of 
prototyping.  This  chapter  provides  a  framework  for  an  analysis  of  UOES  risk 
management  issues  in  this  thesis. 

B.  RISK  MANAGEMENT  IN  THE  DEPARTMENT  OF  DEFENSE 

1.  Definitions 

The  Defense  Systems  Management  College  (DSMC)  defines  risk  as  “the 
probability  of  an  undesirable  event  occurring  and  the  significance  of  the  consequence  of 
the  occurrence.”  [Ref.  3:  p.  3-1]  The  first  factor  in  this  definition,  probability  of 
occurrence,  is  associated  with  the  prioritization  of  risks.  Program  managers  (PMs) 
should  not  overlook  the  second  factor,  significance  of  the  consequence.  Consideration  of 
the  impact  of  an  occurrence  can  enable  a  PM  to  progress  away  from  strictly  prioritized 
risk  management.  When  a  PM  considers  both  factors  together,  the  result  is  a  more 
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realistic  expected  value  of  the  risk.  With  this  more  accurate  assessment,  the  PM  can 
make  more  informed  decisions.  For  example,  the  PM  may  choose  to  accept  risks  where 
the  probability  of  occurrence  is  high,  but  where  the  consequence  of  occurrence  is 
minimal.  He  or  she  can  then  more  efficiently  allocate  resources  toward  the  areas  where 
the  expected  pay-off  is  higher  or  total  risk  is  lower. 

2.  Types  of  Risk 

DSMC  lists  five  facets,  or  types,  of  risk.  [Ref.  3:  pp.  3-3  -  3-6] 

a.  Technical  Risk 

This  type  of  risk  includes  the  complexities  associated  with  developing  a 
new  design  to  provide  a  higher  level  of  performance  or  reconfiguration  of  one  or  more 
mature  designs  for  a  new  application.  The  predominant  causes  of  technical  risk  are  the 
user’s  constant  demand  for  greater  performance  and  the  high  rate  of  technology 
developments.  A  design  that  has  high  technical  risk  today  may  be  less  risky  in  the  future 
when  the  designers  have  access  to  improved  resources  and  processing  techniques.  Some 
major  sources  of  technical  risk  are  component  interfaces,  software  design,  requirements 
changes,  and  demand  for  more  performance. 

b.  Programmatic  Risk 

This  type  of  risk  refers  to  external  forces  that  influence  a  program’s 
direction.  External  forces  are  outside  a  PM’s  span  of  control.  Progranunatic  risks  stem 
from  variance  between  the  environment  for  which  a  PM  planned  and  the  actual 
environment.  Some  major  sources  of  programmatic  risk  are  political  advocacy,  changing 
funding  profiles,  and  regulatory  changes.  A  sudden  shift  in  any  of  these  external  sources 
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may  produce  a  very  disruptive  ripple  through  a  program.  This  disruption  may  result  in  an 
inability  to  achieve  desired  performance  within  acceptable  cost  or  schedule. 

c.  Supportability  Risk 

This  type  of  risk  is  associated  with  fielding  and  maintaining  systems  that 
are  in  development.  Although  a  system  is  technically  producible  and  has  low 
programmatic  risk,  unique  technologies  or  maintenance  requirements  may  result  in  a  life- 
cycle  cost  that  is  unaffordable.  Some  major  sources  of  supportability  risk  are  reliability, 
maintainability,  interoperability,  transportability,  and  training. 

d.  Schedule  Risk 

Schedule  risk  is  the  probability  that  the  actual  time  required  to  achieve 
specific  objectives  will  exceed  the  allocated  time  and  the  significance  of  this  occurrence. 
Some  critical  program  management  schedule  issues  are:  the  length  of  time  required  to 
adequately  resolve  technical  issues,  time  limitations  associated  with  appropriated  funds, 
and  system  readiness  to  test  when  facilities  are  available. 

e.  Cost  Risk 

Cost  risk  is  a  product  of  the  probability  and  impact  of  an  actual  cost  that 
exceeds  the  budgeted  cost  baseline.  In  turn,  increased  risk  in  other  areas  has  a  cumulative 
effect  on  cost  risk.  Solutions  to  technical  and  supportability  issues  often  require 
additional  funds  to  resolve.  When  a  PM  accelerates  or  stretches  a  schedule,  there  are 
adverse  effects  on  cost.  An  increased  cost  estimate  tends  to  decrease  political  support. 
This  fluctuation  may  result  in  increased  scrutiny,  a  funding  profile  that  is  stretched  over  a 
longer  period,  or  a  fixed  funding  profile  with  a  corresponding  reduction  in  the  number  of 
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units  bought.  Because  cost  risk  is  an  indicator  of  risk  in  other  types  of  risk,  cost  estimates 
are  harder  to  define  when  there  is  significant  risk  in  other  areas. 

3.  Risk  Management  Structure 

There  are  four  separate  but  related  activities  that  are  part  of  the  DSMC  risk 
management  structure.  This  structure  helps  a  PM  to  develop  an  effective  and  responsive 
risk  management  plan. 

a.  Risk  Planning 

The  purpose  of  this  activity  is  to  eliminate,  minimize,  or  contain  the 
effects  of  undesirable  occurrences.  Risk  is  present,  to  some  degree,  in  every  program  at 
every  stage  of  development,  production,  or  sustainment.  Therefore,  risk  planning  should 
be  a  continuous  process,  and  personnel  from  every  functional  area  should  contribute  to 
the  process.  PMs  have  a  wide  degree  of  freedom  to  tailor  their  Risk  Management  Plans 
to  their  programs’  unique  needs.  Most  PMs  formally  assess  their  risks  at  least  quarterly. 
From  this  formal  assessment,  PMs  allocate  resources,  as  necessary,  to  keep  their 
programs  within  acceptable  limits.  [Ref.  3:  p.  4-3] 

b.  Risk  Assessment 

This  activity  identifies  risks  and  produces  a  preliminary  quantification  of 
their  probability  and  impact.  During  this  activity  the  most  critical  step  is  identification. 
This  step  entails  a  thorough  phase  by  phase  consideration  of  the  program  to  seek  out  what 
functions  or  technologies  will  be  a  risk  to  the  program.  The  initial  quantification  step 
makes  a  relative  ranking  of  risk  areas.  [Ref.  3:  p.  4-8] 
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c.  Risk  Analysis 

This  activity  builds  on  the  preliminary  assessment  and  produces  an  in- 
depth  sensitivity  analysis  of  the  areas  having  the  greatest  expected  impact.  Risk  analysis 
is  essentially  a  war-gaming  of  various  risk  handling  courses  of  action  to  determine 
expected  consequences.  A  key  output  of  this  analysis  is  a  watchlist;  this  is  a  recognizable 
list  of  critical  risks  in  the  program.  A  watchlist  addresses  potential  risk  events  and  the 
areas  impacted.  [Ref.  3:  p.  4-9] 

d.  Risk  Handling 

This  activity  includes  the  actions  taken  to  address  the  risk  issues  that  were 
previously  identified  during  a  risk  assessment.  There  are  four  management  techniques  to 
influence  the  expected  impact  of  a  risk.  [Ref.  3:  p.  4-10  -  4-13] 

•  Risk  avoidance  includes  basing  a  design  on  a  low  risk  technology;  however,  a 
strict  risk  avoidance  policy  results  in  a  constraint  on  design  flexibility  and  its 
ability  to  meet  the  user’s  demand  for  greater  performance. 

•  Risk  control  is  the  most  common  and  most  involved  of  the  handling  techniques;  it 
is  a  process  of  continuous  monitoring  and  refinement  of  the  program.  To  carry 
out  risk  control,  a  PM  establishes  risk  acceptance  criteria  and  measurable 
thresholds  for  risk.  He  or  she  uses  these  criteria  and  other  relevant  metrics  to 
monitor  the  watchlist  areas  and  better  determine  their  program’s  status  in  terms  of 
risk. 

•  Risk  assumption  is  a  calculated  decision  to  accept  the  consequences  if  the 
undesirable  event  occurs.  Not  all  risks  can  or  should  be  avoided.  For  example, 
schedule  pressures  may  influence  a  PM  to  assume  technical  risk. 

•  Risk  transfer  is  similar  to  assumption,  but  using  this  technique  a  PM  shares  some 
of  the  risk  with  another  interested  party.  Co-development  of  a  system  is  a  method 
to  share  a  risk  with  other  potential  users.  A  PM  may  also  transfer  a  portion  of  the 
program’s  risk  to  the  contractor  by  the  type  of  contract,  performance  incentives, 
or  a  warranty. 
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C.  PROTOTYPING  AS  A  RISK  HANDLING  ACTIVITY 

1.  Prototype 

A  prototype  is  a  model  of  a  system  design  used  to  aid  in  development  of  follow- 
on  refined  versions  of  the  same  system.  A  prototype  may  be  full  scale  or  reduced  size. 
Reduced  size  prototypes  are  based  on  assumptions  about  proportionality  and  scaling  that 
should  be  validated  before  commitment  to  a  particular  design.  A  model  may  be  of  a 
complete  system,  or  it  may  be  a  model  of  certain  high  risk  modules  of  a  complete  system. 
A  model  may  be  a  fabrication  of  a  portion  of  a  system  that  focuses  on  immature  and  high 
risk  elements.  It  may  not  be  necessary  to  integrate  mature  and  low  risk  elements  into  the 
structure.  The  purpose  of  a  prototype  is  to  answer  four  questions: 

•  Is  the  concept  feasible? 

•  Does  the  design  work  the  way  it  is  supposed  to  work? 

•  Does  the  system  provide  a  useful  military  capability? 

•  Does  the  design  meet  the  performance  requirement? 

Answers  to  these  questions  provide  feedback  on  technical  and  supportability  risks. 
Armed  with  this  information,  the  concerned  parties  can  make  more  informed  choices 
regarding  risk  management  stmcture.  This  definition  of  prototyping  and  the  focus  of 
these  questions  are  key  to  understanding  the  usefulness  of  prototypes.  [Ref.  4:  p.2  ] 

In  response  to  a  risk  assessment,  PMs  may  consider  prototyping.  Prototyping  may 
be  a  cost-effective  risk  handling  activity  to  update  and  refine  any  assumptions  made 
during  risk  assessment  and  risk  analysis.  Prototyping  may  help  avoid  premature 
conunitment  of  production  resources. 
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Prototyping  is  a  common  acquisition  management  technique  that  provides 
feedback  on  initial  assumptions  made  in  risk  assessment  and  risk  analysis. 

Understanding  technical  risk  is  an  immediate  beneficiary  of  prototyping.  Experience 
gained  from  operating  a  prototype  can  also  define  supportability  issues.  Schedule  and 
cost  indicators  can  be  defined,  and  because  prototyping  requires  a  partial  development, 
these  risks  may  be  reduced  for  following  development  phases.  Demonstrations  of  a 
system’s  increasing  effectiveness  to  sponsors  may  help  reduce  programmatic  risk.  Each 
of  these  sources  of  feedback  enables  better  decision  making  in  risk  planning  and  risk 
handling. 

2.  Prototyping  Methods 

Information-age  technology  has  produced  a  wide  range  of  prototyping  methods. 
Traditional  methods  of  prototyping  range  from  hand  carving  scaled  models  out  of 
relatively  inexpensive  materials,  to  machining  required  materials  at  full  scale  and  with 
full  functionality.  Inexpensive  scaled  models  provide  considerably  less  feedback  than  full 
scale  operational  models.  Cost  of  the  prototyping  effort  increases  as  the  degree  of 
functionality  increases.  For  some  developments,  traditional  methods  of  prototyping  are 
too  expensive  and  require  more  time  than  the  expected  feedback  is  worth.  However, 
many  limitations  associated  with  traditional  methods  of  prototyping  are  quickly  fading. 

An  explosion  of  new  technologies  is  expanding  the  limits.  New  prototyping  technologies 
center  around  three  interrelated  prototyping  methods,  which  are  rapid  component 
prototyping,  software  prototyping,  and  virtual  prototyping. 
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a.  Rapid  Component  Prototyping 

Rapid  component  prototyping  is  an  extension  of  progress  in  computer 
aided  design  (CAD).  CAD  produces  digital  specifications  for  a  part;  then  an  automated 
pattern-making  machine  uses  that  digital  design.  Master  patterns  for  castings  and  metal 
molds  are  made  with  little  or  no  hard  tooling.  Rapid  component  prototyping  takes  a 
matter^  days,  whereas  traditional  hard  tooling  could  take  months.  This  time-saving 
advantage  enables  developers  to  experiment  with  various  designs  and  materials. 

Rapid  component  prototyping  produces  a  physical  product.  Engineers 
pass  the  item  to  users  and  sub-contractors;  this  aids  in  communication  of  expectations  for 
form,  fit,  and  function.  A  physical  example  more  effectively  communicates  technical 
ideas  to  all  audiences  than  traditional  methods  such  as  technical  drawings.  In  the  1990s, 
stereolithography  (SLA)  is  a  popular  rapid  component  prototyping  process  among 
aerospace  contractors. 

SLA  units  build  plastic  parts  by  mathematically  slicing  CAD  designs  into 
thin  cross  sections.  An  ultraviolet  beam  traces  each  layer  in  a  vat  of 
photosensitive  chemicals  that  solidify  as  they  are  irradiated.  After  each 
layer  is  completed,  the  elevator  holding  the  part  moves  down  about  five 
mils  and  the  next  layer  is  solidified  on  top  of  it.  SLA  machines  produce 
parts  at  a  rate  of  one  vertical  inch  every  two  hours.[Ref.  5:  p.  19] 

Rapid  component  prototyping  enables  use  of  better  materials  in  the 
proeess.  Improved  resins,  molds,  and  adhesives  result  in  rapid  prototypes  that  more 
closely  resemble  the  objective  product’s  characteristics.  Other  terms  industry  uses  for 
rapid  component  prototyping  technology  are  desktop  manufacturing,  ffee-form 
manufacturing,  and  3-D  printing  systems. 
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b.  Software  Prototype 

Application  of  computer  aided  software  engineering  (CASE)  techniques  to 
a  previously  manual  software  development  process  makes  rapid  software  prototypes 
possible.  Communication  of  needs  between  user  and  designer  is  probably  most  difficult 
in  software  development.  Software  is  an  abstract  product  that  relies  heavily  on  precise 
definitions,  functions  and  interfaces;  these  characteristics  compound  the  software 
requirements  communication  problem. 

The  literature  addresses  a  variety  of  software  design  typologies,  and  some 
software  prototypes  are  called  rapid  software  prototypes.  Two  dominant  classes  of 
software  prototypes  are: 

•  Expendable  -  the  code  is  discarded  after  it  has  helped  to  address  the  user’s 
requirements,  and  the  prototypes  are  not  reused  in  the  final  system. 

•  Evolutionary  -  the  prototypes  are  iteratively  built  upon  to  achieve  the  objective 
system,  and  prototypes  are  reused  in  the  final  system.  [Ref.  6:  p.4] 

To  overcome  difficulties  in  communication  of  requirements,  software 
prototype  developers  produce  a  very  limited  prototype  of  what  they  think  the  user  wants. 
This  original  version  prototype  may  be  expendable  or  evolutionary.  It  usually  contains  a 
very  small  percentage  of  the  number  of  lines  of  code,  objects,  or  feature  points  that  the 
objective  system  will  contain.  Users  try  the  software  to  verify  that  developers  have 
addressed  their  problem.  Users  make  their  comments,  and  developers  incorporate  these 
comments  to  refine  the  product  to  better  fit  user  expectations.  This  process  continues 
until  user  and  developer  have  addressed  all  the  issues  and  reached  an  agreement  on  what 
is  a  realistic  product. 
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A  typical  software  prototype  development  process  is: 

•  Identify  basic  requirements:  identify  essential  features;  completeness 
is  not  important. 

•  Develop  a  working  prototype:  this  should  be  accomplished  very 
quickly  (e.g.,  an  “overnight”  development  of  a  prototype). 

•  Implement  and  use:  hands-on  use  of  the  system  provides  experience, 
understanding,  and  evaluation. 

•  Revise  and  enhance:  undesirable  or  missing  features  identified  by  the 
user  must  be  corrected. [Ref.  6:  p.  7] 

An  example  of  software  prototyping  comes  from  Jet  Propulsion 
Laboratory  (JPL)  at  California  Institute  of  Technology.  JPL  established  a  Flight  Projects 
Office  Information  Systems  Testbed  (FIST)  to  determine  if  it  was  possible  to  construct  a 
seamless  networked  telemetry  processing  system  for  use  on  space  missions.  JPL’s 
guidelines  to  the  FIST  team  were  to  use  coimnercial  off  the  shelf  (COTS)  items,  use 
emerging  industry  standards  for  protocols  and  interfaces,  and  maximize  portability  across 
different  vendors’  platforms.  JPL’s  goal  was  to  enhance  its  ability  to  efficiently  take 
advantage  of  an  explosion  in  new  hardware  technology.  Previously,  infusion  of  new 
hardware  required  a  major  redesign  of  JPL’s  telemetry  processing  systems.  The  FIST 
team  used  an  evolutionary  prototype  for  the  new  architecture.  The  team  selected  this 
approach  for  risk  control,  shortened  development  cycle,  and  accelerated  technology 
transfer.  Two  JPL  engineers  commented: 

Unlike  a  throw-away  prototype,  which  is  useful  when  many  of  the 
aspects  of  a  design  are  untried,  evolutionary  prototypes  are  robust  in 
design  and  are  built  upon  a  foundation  that  is  well-understood.  It  is  a  fast 
and  cost-effective  method  of  proving  out  new  concepts  and  accelerating 
their  simultaneous  integration  into  operational  environments  and  next- 
generation  products. 
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Evolutionary  prototyping  concludes  in  the  worst  case  with  a  small- 
scale,  limited  distribution  product  for  operational  environments,  and  in  the 
best  case  leads  to  full-scale  development  of  multi-user  and  multi-mission 
systems.  [Ref.  7:  p.  466] 

In  summary,  software  development  is  a  difficult  and  complex  topic. 
Software  prototyping  is  an  effective  and  widely  used  development  tool.  Use  of  software 
prototypes  allows  developers  to  avoid  investment  of  thousands  of  man-hours  that 
produces  a  grand  software  design,  only  to  find  their  product  is  far  from  user  expectations. 

c.  Virtual  Prototype 

Virtual  prototyping  is  an  extension  of  technologies  that  make  both 
component  and  software  prototyping  possible.  Once  a  system  design  is 
represented  in  a  useable  digital  format,  as  required  for  component  prototyping,  a 
prototype  of  the  associated  system’s  software  can  operate  from  that  digital 
database  as  if  a  physical  system  is  on-line. 

The  DOD  defines  a  virtual  prototype  as; 

A  computer-based  simulation  of  systems  and  subsystems  with  a  degree  of 
functional  realism  comparable  to  a  physical  prototype.  Virtual  prototyping 
is  the  process  of  using  a  virtual  prototype,  in  lieu  of  a  physical  prototype, 
for  test  and  evaluation  of  specific  characteristics  of  a  candidate  design 
[Ref.  8:  p.  26]. 

An  in-orbit  repcdr  of  the  Hubble  Space  Telescope  (HST)  was  possible 
because  of  virtual  prototyping.  A  problem  with  HST  arose  when,  shortly  after 
deployment  to  its  earth  orbit,  some  of  its  ultra-sensitive  lenses  and  mirrors  failed  to  focus. 
National  Aeronautics  and  Space  Administration  (NASA)  scientists  had  a  one-shot 
opportunity  for  an  in-orbit  retrofit.  Space  Shuttle  astronauts  could  deliver  corrective 
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mirrors  to  the  telescope,  but  HST’s  design  was  too  small  for  astronauts  to  work  inside  its 

interior  case.  Astronauts  could  only  place  repair  parts  on  motorized  arms  on  the  exterior 

of  HST.  Engineers  had  to  design  corrective  mirrors  within  the  motorized  arms’  ability  to 

place  them  in  a  precise  position  inside  the  compact  telescope.  NASA  had  to  be  certain 

the  retrofit  parts  were  sufficient  to  correct  the  improper  focus  and,  at  the  same  time,  be 

within  the  motorized  arms’  highly  specialized  capability.  NASA  turned  to  virtual 

prototyping  to  define  their  limitations. 

Such  a  prototype  would  be  an  accurate  ‘working  model’  of  the  Corrective 
Optics  Space  Telescope  Axial  Replacement  (COSTAR).  It  would  exist 
not  as  physical  hardware  but  as  numbers  in  a  computer  memory 
representing  COSTAR’ s  dimensions,  optical  characteristics,  and  the  range 
of  motion  of  all  its  moving  parts.  [Ref.  9:  p.  34] 

A  virtual  prototype  permitted  NASA’s  engineers  to  perform  tasks  that 
otherwise  would  have  been  impossible.  It  allowed  engineers  to  “look”  inside  the  HST, 
from  any  angle  with  unrestricted  access.  NASA  also  experienced  some  spin-off 
advantages  from  virtual  prototyping.  For  example,  they  found  it  very  beneficial  in  cross¬ 
functional  communication  of  specifications  and  interaction  of  intricate  designs.  In 
general,  giving  teams  of  engineers  skilled  in  separate  disciplines  visual  access  to  each 
other’s  designs  helped  minimize  errors.  [Ref.  9:  p.  38] 

3.  Applications  of  Prototyping  Methods 
a.  Competitive  Prototypes 

PMs  can  use  prototypes  to  compare  suitability  of  competing  developers’ 
designs.  Competing  developers  receive  the  requirement,  information  about  testing 
conditions,  and  evaluation  criteria.  They  design  and  produce  their  best  effort,  then  a 
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Source  Selection  Evaluation  Board  (SSEB)  evaluates  the  competitors’  prototypes  to 
determine  the  most  suitable  design. 

DOD  Instruction  5000.2  required  major  defense  acquisition  programs  to 
contract  for  competitive  prototypes  during  DEMA'^AL.  The  purpose  of  this  requirement 
was  to  use  competition  during  early  design  to  help  develop  one  or  more  different  design 
approaches.  The  milestone  decision  authority  (MDA)  could  waive  the  competitive 
prototype  requirement.  A  waiver  had  to  be  based  on  a  cost  benefit  analysis  that  indicated 
competitive  prototyping  increased  technical,  supportability,  and  programmatic  risks  more 
than  it  decreased  cost  and  schedule  risks.* 

The  U.S.  Air  Force  F-22  Advanced  Tactical  Fighter  is  a  highly  visible 
example  of  a  competitive  prototype  strategy.  The  PM  funded  two  competing  contractor 
teams  to  demonstrate  high  technical  risk  prototypes.  They  could  use  their  own  mixture  of 
off-the-shelf  equipment  and  new  technologies  to  control  those  risks.  The  source  selection 
authority  (SSA)  encouraged  contractors  to  demonstrate  additional  technologies  they 
thought  would  enhance  the  aircraft’s  mission  or  control  risk.  Competitors  submitted  their 
pre-test  estimates  of  how  well  they  thought  their  designs  would  perform.  The  SSA  used 
the  accuracy  of  these  self-assessments  to  help  determine  which  contractor  team  had  the 
best  control  over  its  design  process.  [Ref.  10:  p.  8] 


*  Since  THAAD’s  Acquisition  Strategy  was  approved  at  its  21  January  1992  Milestone  I  Decision,  the 
DOD  Instruction  5000.2  was  revised  in  March  1996.  This  revised  version  allows  more  flexibility  in 
this  area.  It  now  advises  ’’Competitive  prototyping  and  competitive  alternative  sources  shall  be  used 
where  practicable.” 
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b.  Advanced  Concept  Technology  Demonstration 
In  June  1994,  DOD  initiated  Advanced  Concept  Technology 
Demonstration  (ACTD)  programs.  The  purpose  of  these  applications  of  prototyping  is  to 
increase  the  pace  at  which  state-of-the-art  technologies  get  to  users.  The  ACTD  program 
is  not  itself  a  prototyping  method,  but  developers  may  employ  one  or  more  prototyping 
methods^to  demonstrate  an  available  technology.  Through  the  prototype  users: 

•  Can  experiment  with  the  technology  in  their  operational  environment  for  up  to 
two  years. 

•  Develop  a  better  early  understanding  of  how  the  technology  can  influence 
their  tactics,  techniques,  and  procedures. 

•  Can  influence  the  design  while  it  is  still  fluid. 

An  ACTD  is  not  a  formal  acquisition  program,  but  if  the  demonstrated 
capability  is  beneficial  to  users,  it  may  become  a  formal  program.  Some  DOD  guidelines 
for  ACTD  selection  are: 

•  Technology  should  address  a  major  operational  need. 

•  Technology  offered  should  be  sufficiently  mature  that  risks  are  minimal. 

•  Users  expect  a  deliverable  and  affordable  system. 

•  Demonstration  should  take  no  more  than  three  years. 

•  Developers  identify,  understand,  and  accept  the  risks. 

•  Residual  prototypes  receive  two  years  of  funding  after  the  demonstration. 

•  Sponsor  is  fully  committed  to  participation. 

There  are  three  possible  outcomes  for  an  ACTD: 

•  User  determines  the  technology  does  not  meet  their  need  or  is  not  suitable. 

•  User  keeps  residual  equipment  and  does  not  request  further  acquisition. 

•  User  formally  requests  acquisition  of  the  technology.  [Ref.  1 1:  p.  5] 

The  ACTD  program  is  an  improvement  over  its  predecessor,  the 
Advanced  Technology  Demonstrations  (ATD)  program.  Options  available  for  the 
Medium  Altitude  Endurance  Unmanned  Aerial  Vehicle  (UAV)  highlight  differences. 
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As  an  ATD  this  program  would  build  two  or  three  air  vehicles,  test 
the  system,  demonstrate  it  to  users,  and  then  leave  them  without  the  new 
capability.  Under  the  new  ACTD  program,  a  total  of  10  UAVs  will  be 
procured  to  provide  a  militarily  significant  quantity  for  user  evaluation  and 
to  assure  a  residual  capability.  This  could  offer  important  benefits  in 
today’s  unsettled  world.  [Ref.  12:  p.  24] 

D.  PROTOTYPING  AS  PART  OF  AN  ACQUISITION  STRATEGY 

A  PM  must  decide  when  to  use  prototyping  to  handle  risk.  Several  recent  studies 
have  provided  some  indicators  that  can  aid  in  this  decision.  This  section  reviews  two  of 
those  studies. 

1.  Institute  for  Defense  Analysis  Prototyping  Study 

A  new  program  can  benefit  from  the  experience  of  programs  that  have  made  it  to 
production  and  deployment.  One  source  of  empirical  evidence  is  a  1991  Institute  for 
Defense  Analysis  (IDA)  study  of  51  major  defense  programs  during  1971-1991.  Of  the 
51  programs,  17  included  development  of  a  complete  system  prototype.  The  other  34 
programs  did  not  include  development  of  either  complete  system,  partial  system,  or  sub¬ 
system  prototypes.  [Ref.  13:  p.  A-2,  A-3] 

The  IDA  study  recommended  prototyping  for  systems  that  involved: 

•  new  performance  or  manufacturing  technologies  for  the  contractor(s). 

•  high  cost  per  unit  and  large  production  quantities. 

•  long  lead  time  or  high  cost  to  correct  potential  unforeseen  problems. 

Figure  3  represents  an  average  of  cost  data  from  the  51  programs  in  IDA's  study. 
This  analysis  indicates  investment  in  prototyping  helps  to  control  cost  risk.  Each  bar 
represents  an  average  ratio  of  actual  cost  to  estimated  cost.  The  graph  groups  the  ratios  by 
prototyped  and  non-prototyped  systems  during  development  and  production. 
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Figure  3.  Impact  of  Prototyping  on  Cost  Growth,  After  Ref.  [13] 


This  graph  indicates  that  both  development  cost  growth  and  production  cost  growth  were 


significantly  less  for  programs  that  prototyped.  Prototyping  had  more  impact  on 


development  cost  growth  than  on  production  cost  growth. 


Figure  4  suggests  prototyping  tended  to  increase  schedule  risk.  This  graph 


displays  the  average  of  actual  months  from  Milestone  I  (MS  I)  and  Milestone  n  (MS  H)  to 


initial  operational  capability  (IOC).  Practically  all  schedule  impact  occurred  during 


DEMA^AL.  On  average,  after  a  MS  n  decision,  there  was  no  significant  difference 


between  the  programs  that  prototyped  or  those  that  did  not  prototype. 


Impact  of  Prototyping  on  Cost  Growth 
For  51  Major  Defense  Programs 


Development  Cost  Production  Cost  Total  Program  Cost 

Growth  Growth  Growth 
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Impact  of  Prototyping  on  Schedule 
For  51  Major  Defense  Programs 
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Figure  4.  Impact  of  Prototyping  on  Schedule,  After  Ref.  [13] 

The  author’s  analysis  of  data  on  the  5 1  programs  listed  in  IDA’s  study  reveals 
further  evidence  for  the  effectiveness  of  prototyping.  The  statistics  in  Table  2  indicate 
that  prototyping  cost  additional  money  up  front,  but  the  investment  paid  big  dividends  in 
the  form  of  less  cost  risk.  More  importantly,  cost  risk  in  the  prototyped  programs  was 
more  predictable.  The  17  programs  that  prototyped  experienced  an  average  cost  growth 
of  25%.  The  34  programs  that  did  not  prototype  experienced  an  average  cost  growth  of 
46%.  This  statistic  alone  indicates  a  major  advantage  of  prototyping.  However,  the 
difference  between  the  standard  deviations  of  total  cost  growth  reveals  a  more  valuable 
advantage  of  prototyping.  A  .25  standard  deviation  for  the  17  programs  that  prototyped 
versus  a  .57  standard  deviation  for  the  34  programs  that  did  not  prototype  indicates  a 
significant  reduction  in  uncertainty  in  cost  growth. 


MS  I  to  IOC  MS  li  to  KX  Total  Schedule 


25 


Risk  Management  Metric 

Number  of  Programs 

17 

34 

Mean  Total  Cost  Growth  (Above  Estimate) 

25% 

46% 

Standard  Deviation  of  Total  Cost  Growth 

.25 

.57 

Mean  Months  From  MS  I  to  IOC  . 

127 

104 

Table!.  Summary  of  Program  Results 


2.  RAND  Corporation  Prototyping  Study 

RAND  Corporation  produced  a  1992  prototyping  study  for  the  Under  Secretary  of 
Defense  for  Acquisition  &  Technology  (USD(A&T)).  This  study  is  based  on  experience 
of  weapons  programs  from  1960  to  1991,  and  during  most  of  this  period  only  traditional 
prototyping  methods  were  available.  (Rapid  component  prototyping,  software 
prototyping,  and  virtual  prototyping  methods  are  recent  trends,  and  their  impact  is  not 
separately  identified.) 

The  RAND  study  suggests  the  advantages  of  prototyping  in  general  are: 

•  Identifies  critical  system  integration  issues;  decreases  technical  risk. 

•  Permits  more  accurate  cost,  schedule,  and  performance  estimates;  decreases 
cost,  schedule,  and  technical  risks. 

•  Reduces  cost  consequence  of  proceeding  into  next  phase  with  poor  design; 
decreases  cost,  technical,  and  supportability  risks. 

•  Allows  necessary  design  changes  to  be  identified  early;  decreases  technical 
and  supportability  risks. 

•  Helps  communicate  specifications  and  intricate  designs;  decreases  technical 
risk. 

The  RAND  study  also  suggests  the  disadvantages  of  prototyping  in  general  are: 

•  Adds  two  years,  on  average,  from  program  initiation  to  IOC;  increases 
schedule  risk. 

•  Increases  preliminary  costs;  increases  early  cost  risk. 

•  Delays  major  funding  commitment;  increases  programmatic  risk. 
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The  RAND  study  concluded  that  some  form  of  prototyping  is  almost  always 
appropriate.  It  found  that  prototyping  will  generate  information  to  improve  the  quality  of 
decision  making  in  an  environment  of  risk  and  uncertainty.  [Ref.  14:  p.73] 

E.  CHAPTER  SUMMARY 

This  chapter  is  the  framework  for  an  analysis  of  THAAD’s  acquisition  strategy 
and  its  risk  management  issues  in  Chapter  IV.  The  chapter  reviewed:  (1)  DSMC’s 
approach  to  risk  management  in  acquisition  strategies,  (2)  some  current  methods  and 
applications  of  prototyping,  and  (3)  two  recent  studies  regarding  the  role  of  prototyping  in 
weapon  system  development.  The  recent  advances  in  prototyping  methods  should 
enhance  the  advantages  and  reduce  the  disadvantages  of  prototyping.  These  advances 
should  make  prototyping  more  accessible  and  valuable  in  DOD  acquisition. 
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in.  THEATER  HIGH  ALTITUDE  AREA  DEFENSE  SYSTEM 


A.  PURPOSE 

This  chapter  provides  a  description  of  the  THAAD  system.  This  description  is 
generally  based  on  program  accomplishments  and  future  plans  through  DEMA^AL  flight 
test  five,  which  took  place  in  March  1996.  It  describes:  (1)  plans  for  how  THAAD  will 
be  used  in  an  operational  deployment,  (2)  the  system’s  four  major  subsystems,  and  (3)  the 
major  cost,  schedule,  and  performance  differences  between  the  operational  prototype  and 
the  objective  system.  This  knowledge  of  THAAD  is  essential  for  understanding  the 
analysis  of  THAAD’ s  acquisition  strategy  in  Chapters  IV  and  V. 

B.  OPERATIONAL  CONCEPT 

The  U.  S.  Army  Program  Executive  Office  (PEO)  for  Missile  Defense  is 
developing  THAAD  as  the  upper  tier  of  the  two  tiered  Active  Defense  pillar  of  joint 
theater  missile  defense.  THAAD’ s  Operational  Requirement  Document  (ORD)  calls  for 
near  leak-proof  defense,  which  will  provide  high  confidence  of  threat  intercept.  [Ref  15] 

THAAD  firing  batteries  will  function  in  an  operational  deployment  as  displayed 
in  Figure  5.  The  system  has  several  notable  features,  which  include: 

•  Autonomous  operations  or  joint  operations. 

•  Early  warning  and  threat  cueing  to  lower  tier  assets. 

•  Remote  launch  capability. 

•  Hit-to-kill  technology. 

•  Shoot-look-shoot  capability.  [Ref  16] 

The  system  may  operate  in  an  autonomous  mode,  or  it  may  operate  with  external  BM/C3I 
systems.  Among  these  external  interfaces  may  be  an  Air  Force  Command  and 
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Figure  5.  THAAD  Operational  Deployment.  From  Ref.  [16] 


Reporting  Center  (CRC),  the  Joint  Tactical  Ground  Station  (IT AGS),  or  a  Force 
Protection  Tactical  Operations  Center  (FTTOC)[Ref.  17].  In  either  mode  of  operation, 
the  system  will  provide  sufficient  range  to  intercept  incoming  ballistic  missiles  up  to  the 
edge  of  the  earth’s  atmosphere. 

THAAD  will  also  provide  critical  early  warning  to  a  lower  tier  missile  defense. 
Lower  tier  systems  are  generally  point  defense  systems  that  provide  much  less  coverage 
than  THAAD’ s  area  coverage.  The  primary  land-based  lower  tier  system  is  PATRIOT 
P AC-3,  and  it  may  also  include  Medium  Extended-range  Air  Defense  System  or  an 
enhanced  U.  S.  Marine  Corps  HAWK. 

Internally,  the  tactical  operations  center  for  THAAD  uses  two  Battle 
Management/Command,  Control,  Communications,  and  Intelligence  (BM/C3I)  shelters 
for  force  operations  (FO)  and  engagement  operations  (EO).  Multi-use  Launcher  Control 
Stations  (LCS)  provide  communications  links  to  remote  launchers,  which  widens 
THAAD’ s  area  of  coverage. 

The  missile  uses  hit-to-kill  technology  to  destroy  its  target.  THAAD’ s  interceptor 
does  not  have  a  warhead,  but  it  relies  solely  on  its  ability  to  find,  lock  on,  and  destroy  its 
target  using  kinetic  energy. 

THAAD  has  a  shoot-look-shoot  capability.  This  simultaneously  enhances 
lethality  and  missile  conservation  by  making  a  hit  or  kill  assessment  after  an  initial  shot. 
With  this  assessment  the  BM/C3I  element  can  determine  if  the  interceptor  destroyed  its 
target.  If  needed,  a  second  interceptor  can  then  be  launched. 
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C.  EQUIPMENT  OVERVIEW 

THAAD  Project  Office  (TPO)  is  developing  two  distinct  products.  To  meet  the 
legislative  mandate,  a  UOES  package  will  be  the  first  developed  and  delivered  product, 
but  an  objective  system  is  the  ultimate  product.  Table  3,  at  the  end  of  this  chapter, 
summarizes  the  cost,  schedule,  and  performance  differences  between  the  two  products. 

This  acquisition  strategy  meets  the  urgent  need  for  fielding  increased  TMD 
capability.  The  UOES  package  also  supports  the  achievement  of  THAAD’ s  operational 
requirement  by  helping  to  achieve  a  more  suitable  objective  system.  Both  UOES  and  the 
objective  system  have  four  major  subsystems,  consisting  of  launcher,  missile,  TMD 
Ground  Based  Radar  (GBR),  and  a  BM/C3I  element.  These  subsystems  interface  via  a 
complete  software  package,  which  is  approaching  one  million  lines  of  code,  primarily  in 
the  Ada  programming  language.  (The  focus  of  this  introductory  chapter  is  on 
equipment.)  [Ref.  16] 

1.  Launcher 

A  tactical  launcher  subsystem  (Figure  6)  is  mounted  on  a  standard  Palletized  Load 
System  (PLS)  truck.  Use  of  the  PLS  truck  allows  for  autonomous  reload  of  eight  missile 
rounds  per  pallet.  Flight  test  vehicles  (FTV)  one  through  four  used  a  non-tactical  interim 
launcher,  while  the  remaining  ten  flight  tests  will  use  tactical  launchers.  Users  already 
have  daily  access  to  the  first  PLS  launcher,  which  has  successfully  endured  a  300  mile 
off-road  durability  test.  This  first  launcher  also  supported  FTV  five.  Three  more 
launchers  will  be  produced  under  the  DEMA^AL  contract,  and  aU  four  will  be  part  of  the 
UOES  package.  [Ref.  16] 
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Figure  6.  THAAD  Launcher  Mounted  on  a  PLS  Truck,  From  Ref.  [16] 
2.  Interceptor 


THAAD’ s  missile  subsystem  is  composed  of  three  subsystems.  These  critical 
components  are  missile  canister,  propulsion  system,  and  kill  vehicle  (KV).  Figure  7 
shows  the  interceptor  at  the  beginning  of  the  boost  phase  of  flight.  After  assembly,  a 
missile  is  housed  in  its  hermetically  sealed  canister  which  provides  protection  during 
storage  and  shipment.  The  graphite  epoxy  canister  also  serves  as  a  launch  tube.  Once 
sealed  in  its  canister,  a  missile  is  a  certified  missile  round,  which  requires  no  maintenance 
for  a  ten  year  service  life. 
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Figure  7.  THAAD  Flight  Test  Vehicle  Three,  From  Ref.  [16] 


The  propulsion  system  consists  of  a  single  stage  solid  propellant  booster,  a  thrust 
vector  control  (TVC)  system,  and  deployable  aerodynamic  flares.  The  booster's  function 
is  to  deliver  its  kill  vehicle  at  desired  speed  and  to  required  altitude  for  intercept  of  the 
targeted  threat.  During  boost  phase,  the  TVC  system  steers  its  missile;  this  steering 
action  is  detectable  in  Figure  7  near  the  top  of  the  missile.  The  booster's  aerodynamic 
flares  deploy  shortly  after  launch  to  provide  stability  during  flight.  [Ref.  18] 

A  KV  is  the  only  portion  that  actually  intercepts  a  targeted  TBM.  It  is  a  software 
intensive  component  that  can  acquire,  lock-on,  and  then  steer  itself  to  intercept.  All  of 
these  actions  occur  in  a  time  frame  that  may  last  from  seconds  to  less  than  four  minutes. 
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Together  the  KV  and  its  target  have  a  combined  velocity  several  times  the  speed  of 
sound.  The  KV,  which  is  approximately  the  front  22  inches  of  the  THAAD  missile,  uses 
only  the  kinetic  energy  of  the  high  speed  impact  to  destroy  its  target.  [Ref.  16] 

A  two  piece  shroud  covers  the  forecone  during  endoatmospheric  flight.  This 
shroud  reduces  aerodynamic  drag  and  protects  the  seeker  window  from  aerodynamic  heat 
produced  by  the  KV’s  high  speed  flight.  Two  notable  KV  features  are  a  gimbal-mounted 
infrared  (IR)  seeker  and  a  Divert  and  Attitude  Control  System  (DACS).  The  IR  seeker 
“looks”  through  a  rectangular  uncooled  sapphire  window  that  serves  as  the  KV’s  "eyes," 
while  the  DACS  enables  the  KV  to  steer  itself  to  point  of  intercept.  All  of  these  complex 
tasks  are  possible  because  of  an  Integrated  Avionics  Package  (lAP)  that  uses  four  reduced 
instruction-set  computing  (RISC)  computers,  which  provide  the  computational  speed 
required  for  hit-to-kill  guidance.  [Ref.  19:  p.  44] 

3.  Theater  Missile  Defense  Ground  Based  Radar 

THAAD  uses  a  state-of-the-art  X-band  phased  array  radar  that  performs  multiple 
functions.  These  functions  include  surveillance,  acquisition,  tracking  and  classification, 
as  well  as  impact  point  prediction.  The  TMD-GBR  senses  an  incoming  threat  and 
provides  this  information  to  the  BM/C3I  element  to  identify  the  threat  and  prioritize 
multiple  threats.  In  addition  to  tracking  threat  targets,  the  radar  must  also  track  its  own 
in-flight  interceptors  and  provide  in-flight  target  updates  which  aid  the  interceptor  in 
target  homing.  A  kill  assessment  follows  this  sequence  of  tasks.  This  assessment  aids  in 
determination  of  the  need  for  a  second  THAAD  launch  or  for  cueing  to  a  lower-tier 
system.  Figure  8  shows  the  radar  antenna,  cooling  equipment  unit,  electronics  equipment 
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unit,  and  operator  control  unit.  Not  shown  is  the  prime  power  unit,  which  is  similar  in 
size  to  the  cooling  equipment  unit. 


Figure  8.  THAAD  Ground  Based  Radar  and  Support  Equipment,  From  Ref.  [16] 


4.  Battle  Management 

The  BM/C3I  subsystem  is  the  integrating  component  of  the  THAAD  weapon 
system,  and  it  provides  the  interfaces  to  external  systems  for  Joint  Operations.  THAAD’s 
BM/C3I  units  (Figure  9)  are  mounted  on  standard  High  Mobility  Multi-purpose  Wheeled 
Vehicles  (HMMWV).  The  BM/C3I  element  uses  a  Standard  Integrated  Command  Post 
System  (SICPS)  to  provide  crew  and  equipment  protection  from  extreme  environmental 
conditions.  Communications  systems  include:  the  Joint  Tactical  Information  Distribution 
System  (JTIDS)  for  inter-service  operations;  the  Single-Channel  Ground  and 
Airborne  Radio  System  (SINCGARS)  for  internal  command  and  support  requirements; 
and  the  Global  Positioning  System  (GPS)  for  rapid  and  accurate  emplacement.  The  units 


Figure  9.  THAAD  BM/C3I  Shelters,  From  Ref.  [16] 


come  in  two  configurations,  which  are  the  Tactical  Operations  Station  and  the  Launcher 
Control  Station.  Either  configuration  may  provide  workstations  for  force  operations  such 
as  planning,  analysis,  and  logistic  support,  or  it  may  provide  workstations  for  engagement 
operations  such  as  surveillance  and  battle  management.  A  Launcher  Control  Station 
provides  direct  communication  links  for  the  TOC,  or  it  may  serve  as  a  communication 
relay  to  remote  launchers  or  external  sensors  when  a  relay  is  necessary. 

D.  COMPARISON  OF  UOES  TO  THE  OBJECTIVE  SYSTEM 

Table  3  is  an  unclassified  summary  of  the  cost,  schedule,  and  performance  of 
UOES  and  the  objective  system.  There  have  been  numerous  considerations  to  increase  or 
decrease  the  scope  of  either  product.  THAAD’ s  large  budget  attracts  much  attention  from 
the  many  other  contenders  for  DOD  procurement  dollars;  consequently  TPO  has  had  to 
conduct  several  studies  to  determine  the  feasibility  of  combining  some  of  each  product’s 
features  in  an  effort  to  find  ways  to  save  money. 
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Table  3.  Summary  of  Cost,  Schedule,  &  Performance  Trade-off  Between  UOES  &  Objective  SYS  After  Ref.  [18  &  40] 


IV.  SUMMARY  OF  THAAD’S  ACQUISITION  STRATEGY 


A.  PURPOSE 

THAAD's  schedule  is  widely  recognized  as  aggressive.  This  chapter  describes  the 
key  features  of  THAAD’s  MS  I  acquisition  strategy  and  how  its  features  were  designed  to 
handle  the  risks  perceived. 

Risk  management  terms  used  in  THAAD’s  1992  acquisition  strategy  vary  slightly 
from  the  terms  described  in  Chapter  n.  DOD  risk  management  terminology  often  varies 
from  program  to  program.  Appendix  B  relates  DSMC’s  risk  management  terms  to  terms 
used  in  THAAD’s  acquisition  strategy. 

B.  PRE-MILESTONE  I  ACTIVITIES 

1.  Late  1980s 

A  September  1988  Ballistic  Missile  Defense  Organization  (BMDO)  memorandum 
to  U.S.  Army  Strategic  Defense  Command  (SDC)  was  a  statement  of  need  that  requested 
the  most  expeditious  approach  to  develop  a  THAAD  missile.  At  that  time,  BMDO 
envisioned  THAAD  as  a  new  missile  only,  rather  than  an  entire  system.  BMDO 
encouraged  leveraging  off  past  missile  defense  successes  by  “building  on  the  results  of 
the  High  Endoatmospheric  Defense  Interceptor  (HEDI)...and  the  Kinetic  Kill  Vehicle 
Integrated  Technology  Experiment  (KITE).’’  These  experiments  had  proven  the  hit-to- 
kill  concept  and  made  significant  advancements  in  infrared  seekers,  active  window 
cooling,  and  forebody  cooling.  These  were  the  same  technologies  a  THAAD  missile 
would  likely  use.  [Ref.  20:  p.  2] 
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The  U.S.  Army  Air  Defense  Artillery  School  was  the  user  representative,  and  it 
worked  closely  with  BMDO  to  establish  performance  requirements  in  the  Operational 
Requirements  Document  (ORD).  BMDO  suggested  that  THAAD  should  “overlay” 
existing  and  future  PATRIOT  enhancements;  later  this  grew  into  the  upper  and  lower  tier 
operational  requirement.  BMDO  also  envisioned  a  significant  growth  potential  for 
interoperability  and  battlefield  information  sharing.  The  THAAD  missile  would  be 
required  to  “interface  with  existing  and  projected  radars,  launchers,  and  BM/C3I 
networks.”  [Ref.  20:  p.  2] 

The  Air  Defense  School  was  a  strong  proponent  for  significant  user  participation 
in  development  of  the  THAAD  missile.  Regional  commanders  were  demanding  better 
TBM  protection.  Earlier  in  the  1980s,  PATRIOT’S  PM  had  experienced  major  problems 
with  initial  operational  testing.  Those  problems  came  from  lack  of  user  input  into  the 
operations  and  maintenance  concepts.  As  a  result,  it  required  a  total  of  six  operational 
tests  to  field  PATRIOT.  With  THAAD,  the  Air  Defense  School  insisted  on  greater 
participation.  [Ref.  21] 

2.  Early  1990s 

In  September  1990,  shortly  after  deployments  to  Operation  Desert  Shield  began,  a 
second  BMDO  letter  re-affirmed  the  urgent  need  for  THAAD.  This  letter  formally 
initiated  the  program’s  Concept  Definition  (CD)  phase.  BMDO  also  enlarged  THAAD’ s 
scope  to  develop  a  complete  weapon  system  rather  than  a  missile  only.  By  January  1991 
BMDO  accelerated  THAAD’ s  schedule  and  called  for  a  demonstration  system  to  be 
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capable  of  emergency  deployment  in  1995.  The  legislative  mandate  for  an  operational 
capability  was  expressed  in  the  Missile  Defense  Act  of  1991.  [Ref.  20:  p.  2] 

THAAD’s  increased  scope  and  its  schedule  acceleration  were  a  direct  result  of 
world  events.  Between  1988  and  1991  the  Soviet  Union  had  collapsed,  and  the  emphasis 
of  U.S.  National  Military  Strategy  began  to  shift  toward  rapid  force  projection.  This 
required  greater  flexibility  in  terms  of  transportability.  The  only  defensive  system, 
PATRIOT,  was  air  transportable,  but  it  required  far  more  C-5  aircraft  than  were  readily 
available.  Furthermore,  Operation  Desert  Storm  highlighted  PATRIOT’S  limited  TBM 
defensive  capability.  The  increased  visibility  of  the  growing  ballistic  missile  threat 
justified  the  schedule  acceleration  and  the  enlarged  size  of  the  program.  [Ref.  21] 

Three  contractor  teams  participated  in  CD  starting  in  August  1990.  The  initial 
objectives  of  this  phase  were  for  competing  contractor  teams  to: 

•  Define  technologies  and  system  concepts  required  for  the  development  of  a 
cost  effective  system;  this  would  help  control  technical  and  cost  risks. 

•  Conduct  system  trade  studies  to  optimize  design  compared  to  schedule, 
technical,  and  cost  risks. 

•  Specify  plans  to  develop  and  demonstrate  high  risk  technologies;  this  would 
help  identify  the  most  appropriate  plan,  given  high  schedule  risk. 

In  December  1991  the  competitors  delivered  their  system  specifications  (Type  A) 
for  their  missile,  launcher,  and  BM/C3I  element  designs.  Due  to  THAAD’s  aggressive 
schedule,  TPO  also  requested  the  teams’  design  specifications  (Type  B)  for  their  missile 
and  launcher.  (B  SPECS  are  usually  not  delivered  until  DEMA^AL  [Ref  22;  p.  1.1-3].) 
They  also  delivered  their  recommendations  based  on  their  trade  studies  and  their  plans  to 
demonstrate  high  risk  technologies. 
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BMDO  staffed  the  ORD  through  the  Joint  Requirements  Oversight  Counsel  to  the 
USD(A&T).  The  MS  I  decision  came  on  28  January  1992  when  the  USD(A«&T) 
approved  THAAD’s  Acquisition  Decision  Memorandum  (ADM).  [Ref.  23:  p.  C-4] 

C.  MILESTONE  I  ACQUISITION  STRATEGY  FOR  DEVELOPMENT 

1.  Expanded  CD  Phase  Objectives 

As  a  result  of  the  program’s  acceleration  and  increased  scope,  the  THAAD  Project 
Office  extended  the  CD  phase  from  December  1991  until  May  1992  to  perform  additional 
risk  handling  or  “risk  mitigation”  activities.  During  this  extension,  the  contractor  teams 
developed  their: 

•  Software  interface  requirements  and  specifications. 

•  Software  requirements  specifications. 

•  Software  development  plans.  [Ref.  23:  p.  C-4] 

2.  Demonstration  and  Validation 

Traditionally  the  purpose  of  this  phase  is  to  demonstrate  critical  processes  and 
technologies.  This  goal  is  often  accomplished  with  very  limited  prototypes  that  focus  on 
high  risk  components.  As  part  of  MS  I  risk  planning,  TPO  established  DEMA^AL 
objectives  that  went  far  beyond  the  traditional  approach.  BMDO’s  objectives  for  this 
phase  were  to  further  develop  and  integrate  technologies  into  an  operational  prototype,  or 
UOES,  that  would  have  a  useful  TMD  capability. 

The  MS  I  strategy  called  for  the  UOES  package  to  include  four  launchers,  four 
BM/C3I  units,  two  TMD-GBR  radars,  and  40  UOES  missiles.  The  prime  contractor 
would  deliver  the  launchers  and  BM/C3I  units  under  the  DEMA^AL  contract.  As  a 
technical  and  supportability  risk  control  measure,  TPO  placed  the  40  UOES  missiles  in  a 
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separate  contract  option.  The  strategy  called  for  exercise  of  that  option  once  the  system 
demonstrated  a  useful  military  operational  capability.  This  arrangement  would  help  TPO 
avoid  the  risk  of  premature  commitment  to  an  immature  design. 

Exit  criteria  for  DEMA^AL  phase  included  requirements  that  the  contractor 
demonstrate,  through  flight  test  and  simulation,  the  design’s  ability  to; 

•  Achieve  target  acquisition. 

•  Complete  BM/C3I  functions. 

•  Achieve  missile  burnout  velocity. 

•  Conduct  in-flight  maneuvers  in  response  to  GBR  updates. 

•  Conduct  KV  terminal  homing,  or  “end  game”  divert  maneuver. 

•  Perform  hit-to-kill  intercept. 

•  Conduct  kill  assessment. 

The  strategy  established  UOES  contract  option  acceptance  criteria,  which  are: 

•  Successful  hardware-in-the-loop  (HWIL)  demonstrations  of  guidance  and 
control  systems. 

•  One  guided  flight  to  intercept  of  a  target  using  a  TMD-GBR. 

UOES  acceptance  criteria  were  a  subset  of  DENWAL  exit  criteria.  The  strategy  called 
for  a  48  month  DEMA^AL  phase,  which  TPO  planned  to  last  from  fourth  quarter  fiscal 
year  (FT)  1992  until  fourth  quarter  FY  1996.  MS  I  estimates  called  for  exercise  of  the 
UOES  option  in  the  fourth  quarter  FY  1995.  [Ref.  23:  p.  C-5] 

To  control  technical  and  schedule  risk,  the  strategy  emphasized  an  event  driven 
program  rather  than  a  schedule  driven  program.  The  event  driven  feature  of  the  strategy 
would  help  control  technical  risk  by  not  rushing  through  the  design  and  interface 
processes  just  to  satisfy  the  legislative  mandate.  The  event  driven  feature  would  also  help 
control  schedule  and  cost  risks  by  allowing  the  flexibility  to  accomplish  some  tasks 
before  they  were  scheduled,  if  that  would  reduce  overall  risk.  [Ref.  18] 
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3.  Engineering  &  Manufacturing  Development 

The  MS  I  acquisition  strategy  allocated  30  months  for  EMD.  This  upcoming 
phase  is  currently  scheduled  for  October  1998  through  March  2001.  The  focus  of 
THAAD’s  EMD  is  to  refine  system  design,  to  validate  a  producible  design,  and  to 
validate  that  the  design  is  fully  supportable  within  the  existing  Army  logistics  structure. 
During  EMD,  an  operationally  deployable  THAAD  battery  will  “own”  the  UOES  interim 
prototype.  The  experience  in  use  and  testing  of  UOES  equipment  will  be  a  valuable 
source  of  user  feedback  to  enhance  the  objective  system’s  suitability.  The  objective 
system  will  differ  from  UOES  because  it  will  incorporate  design  changes  resulting  from 
UOES  and  EMD  testing.  EMD  objectives  include: 

•  Full  qualification  of  all  system  components. 

•  Integrated  logistics  Support  Plan  (ILSP)  completion. 

•  Material  Fielding  Plan  (MFP)  completion. 

•  Functional  and  physical  configuration  audits. 

•  Environmental  testing. 

•  Threat  requirements  and  available  technology  update.  [Ref  23:  p.  C-5] 

4.  Risk  Management  Structure 

The  MS  I  acquisition  strategy  reflected  several  coordinated  and  ongoing  risk 
planning  activities.  Risk  management  for  DEMA^AL  built  upon  the  objectives  that 
contractors  had  met  during  CD  and  its  five  month  extension.  A  risk  assessment  identified 
the  watchlist  areas  that  would  be  the  most  critical  to  the  program’s  success. 

Table  2  is  the  author’s  summary  of  all  the  key  risk  management  issues  addressed  in  the 
MS  I  acquisition  strategy. 
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Facet  of  Risk 
and  Watchlist  Area 


Technical 


•  Radome  heating 


High  altitude  engagement 


System  integration 
Seeker  technology 


Overall  Risk 
Assessment 


Moderate 


Interoperability 


•  Integrated  Logistics 
Support  (ILS) 

•  Weight  &  Size 


Cost 

•  BM/C3I  Software 


KV  Avionics  Package 


Schedule 

•  Complete  resolution  of 
engineering  &  integration 
issues  by  4th  QTR  95 


Moderate  to 
High 


Risk  Handling 
Techniques 


Avoid  &  control  by  using  design  based  on 
existing  technology  or  technology  already  in 
development 

Avoid  &  control  by  maximum  use  of 
commercial-off-the-shelf  items  and  common 
hardware  and  software 
Control  by  encouraging  prime  contractor 
team  with  subcontract  specialists 
Control  by  dual  sourcing  IR  seeker  and 
parallel  development  of  critical  components 


Avoid  &  control  by  requiring  interface  with 
existing  and  projected  systems 
Assume  by  having  contractor  support  UOES 
and  deferring  some  supportability  issues 
until  EMD 

Avoid  by  requiring  C- 130/C- 141  transport 


Control  by  design  based  on  existing 
technology  or  technology  already  in 
development 

Control  by  Monthly  Cost  Performance 
Reports  and  Quarterly  Risk  Assessment 
Reports  &  Performance  Reviews 


Assume  &  control  by  developing  an 
operational,  deployable  prototype  at  the  end 
ofDEM/VAL 

Partially  avoid  by  reducing  environmental 
requirements  until  objective  system 
Partially  avoid  for  UOES  by  having 
contractor  provide  all  maintenance 
Control  by  Contract  requirements  for 

•  Monthly  Cost  Performance  Reports 

•  Quarterly  Risk  Assessment  Report 
Transfer  by  having  NMD  develop  the  radar 
and  provide  a  TMD  version  as  Government 
Furnished  Equipment 
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TPO’s  initial  risk  analysis  found  that  Integrated  Logistics  Support  (ILS)  was  a  low 
risk  area  for  DEMA'^AL  (although  TPO  assessed  that  it  would  become  a  critical  risk  area 
during  EMD).  The  strategy  required  that  the  contractor  establish  an  ILS  Plan  (ILSP) 
during  DEMA^AL,  but  it  did  not  require  a  finalized  ILSP  until  MS  HI.  To  avoid 
additional  schedule  risk,  TPO  determined  it  would  be  more  cost  effective  to  have  the 
contractor  provide  all  maintenance  for  the  UOES  during  its  planned  five  year  life-cycle. 
The  objective  system  is  envisioned  to  use  a  three-level  maintenance  concept.  The  system 
will  be  fully  maintainable  at  the  unit  by  military  personnel  and  will  require  contractor 
support  for  intermediate  and  depot  maintenance.  [Ref.  20:  p.  10] 

5.  Competition  And  Contracting 

Before  gaining  approval  for  its  acquisition  strategy,  TPO  considered  several  other 
alternatives.  To  evaluate  alternatives,  it  was  essential  to  separate  near  and  long  term 
program  objectives.  In  the  long  term,  TPO  was  required  to  deploy  a  complete  tactical 
system  as  soon  as  feasible  at  affordable  cost  and  acceptable  risk.  In  the  near  term,  by  law, 
TPO  had  to  complete  DEMA^AL  as  quickly  as  possible  with  an  operational  prototype. 
This  requirement  was  far  beyond  traditional  MS  II  decision  requirements;  it  meant  TPO 
must  resolve  operational  issues  much  earlier  than  in  the  traditional  acquisition  approach. 

One  alternative  was  competitive  prototyping.  TPO  requested  exemption  from  the 
competitive  prototype  alternative  as  required  by  DOD  policy.  Estimates  indicated 
carrying  two  contractors  through  DEMA^AL  could  add  approximately  $1.2  billion  to 
program  cost.  Furthermore,  dupUcate  testing  would  increase  schedule  risk.  These 
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additional  cost  and  schedule  risks  would  result  in  a  net  risk  increase  under  a  competitive 
prototype  strategy.  [Ref.  23;  p.  C-14]. 

Another  alternative  called  for  two  system  integration  contractors  to  develop  paper 
designs  or  very  limited  component  prototypes  during  a  12  month  period.  These  designs 
would  have  focused  on  high  risk  components,  and  at  the  end  of  the  period  the  contractors 
would  have  submitted  the  designs  for  a  competitive  selection.  TPO  rejected  this 
alternative  because  it  increased  technical  risk.  For  THAAD,  paper  designs  could  not 
answer  the  critical  questions: 

•  Would  the  concept  be  feasible? 

•  Would  the  design  work  the  way  it  was  supposed  to  work? 

•  Will  the  system  provide  a  useful  military  capability? 

•  Will  the  system  meet  the  performance  requirement? 

TPO  recommended  “single  source  with  risk  mitigation”  as  the  best  alternative 
course  of  action.  At  the  MS  I  decision  TPO  gained  approval  to  competitively  select  a 
single  THAAD  system  contractor  for  DEMWAL,  and  that  contractor  would  have  sole 
source  responsibility  for  all  remaining  phases.  To  control  a  myriad  of  risks  associated 
with  a  single  source  development  and  production  contract,  TPO  would  fund  the 
contractor  to  conduct  a  risk  reduction  program,  which  included  implementation  of  a  risk 
mitigation  plan.  This  plan  would  include  dual  sourcing  the  IR  seeker,  parallel 
development  of  critical  components,  and  requiring  the  prime  contractor  to  maximize 
competition  at  the  subcontract  level. 

The  acquisition  strategy  recommended  a  cost-plus-fixed-fee  (CPFF)  contract  for 
DEMA^AL  because  of  technical  and  cost  risks  associated  with  integrating  a  variety  of 
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leading-edge  technologies.  For  HMD,  the  strategy  recommends  a  cost-plus-incentive-fee 
(CPIF).  When  THAAD  reaches  Production  and  Deployment,  the  strategy  recommends  a 
firm-fixed-price  contract.  [Ref.  23:  p.  C-15] 

The  basic  DEMA^AL  contract  includes  development  of  four  launchers,  two 
BM/C3I  units,  20  flight  test  missiles,  and  the  software  required  to  achieve  exit  criteria. 
The  prime  contractor  will  deliver  each  of  these  items  whether  or  not  the  PM  exercises  the 
UOES  contract  option.  Not  included  were  the  GBRs,  which  were  to  be  provided  as  GFE. 
(Radar  development  was  part  of  a  $492.2  million  NMD  contract  that  included 
development  of  a  TMD  version  of  the  GBR).  [Ref.  24:  p.  7] 

TPO  used  full  and  open  competition  to  award  the  DEMA'AL  contract.  A 
synopsis  appeared  in  the  Commerce  Business  Daily  on  10  June  1991  announcing  a  draft 
request  for  proposal  (RFP).  The  draft  proposals  that  were  received  were  used  in  writing  a 
more  definitive  final  RFP.  The  final  RFP  went  out  on  30  January  1992.  The  Source 
Selection  Evaluation  Board  (SSEB)  evaluated  three  contractor  teams’  proposals  and 
reported  its  findings  to  the  Source  Selection  Advisory  Council  (SSAC).  The  SSAC’s 
recommendation  went  to  the  Secretary  of  the  Army,  the  Source  Selection  Authority 
(SSA). 

On  4  September  1992  Lockheed  Missiles  and  Space  Company  (LMSC), 
subsequently  renamed  Lockheed  Martin  Missiles  and  Space  Company,  won  the  contract. 
LMSC  is  now  the  prime  contractor  for  the  DEMA^AL,  EMD,  and  Production  and 
Support  phases.  The  contract  has  an  estimated  cost  of  $695.9  million  with  a  fixed-fee  of 
$57.8  million,  or  8.3%  [Ref.  25:  p.  1]. 
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The  UOES  contract  option  is  for  40  contingency  capability  missiles  and  the 
contractor’s  maintenance  support  through  the  five-year  expected  life  of  the  UOES. 
Estimated  cost  for  the  missiles  is  $73.9  million  with  a  fixed-fee  of  $6.2  million.  The  five 
years  of  complete  contractor  support,  estimated  to  cost  up  to  $90.0  million,  will  be 
included  in  the  EMD  contract.  [Ref.  25:  p.  12] 

6.  Funding  the  Contingency  Reserve  Missiles 

Funding  for  the  UOES  option  has  been  a  complex  legal  issue  that  has  required 
careful  management.  On  one  hand,  there  is  a  specific  legislative  mandate  that  required  an 
operationally  effective  TMD  capability  by  1996.  On  the  other  hand,  DOD  Regulation 
7000. 14-R  places  legal  restrictions  against  using  Research,  Development,  Test  and 
Evaluation  (RDT&E)  funds  to  procure  purely  operational  equipment  [Ref.  41:  p.  5].  The 
appropriated  funds  required  for  the  basic  DEMA^AL  contract  and  the  TMD-GBR  are 
easily  classified  as  RDT&E  funds,  but  funds  for  the  40  missiles  in  the  UOES  option  are 
not  as  easily  classified.  By  definition  the  UOES  missiles  can  not  be  expended  during 
developmental  testing  because  they  must  be  available  for  contingency  deployment. 
BMDO  has  addressed  this  issue  by  emphasizing  the  three  prioritized  purposes  for  the 
UOES.  “The  UOES  will  be  used  for  early  operational  assessment  and  for  soldiers  to 
influence  the  final  design,  but  will  also  be  available  for  use  as  a  contingency  capability 
during  a  national  emergency  [Ref.  26:  p.  A- 19].”  Furthermore,  BMDO  has  recommended 
exemption  to  the  restriction  to  allow  the  40  missiles  to  be  kept  in  contingency  reserve  and 
not  used  for  EMD  testing.  [Ref.  41:  p.  12] 
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D.  CHAPTER  SUMMARY 


The  innovation  found  in  THAAD’s  acquisition  strategy  is  its  commitment  to  exit 
DEMA^AL  with  an  operational  prototype.  This  chapter  presented  the  features  of  how 
TPO  tailored  the  MS  I  strategy  to  address  the  program’s  risks.  To  help  handle  high  risk 
technologies,  TPO  built  the  strategy  upon  advancements  made  in  missile  defense 
experiments  in  the  1980s.  To  handle  the  risks  brought  on  by  an  aggressive  schedule,  TPO 
extended  CD  and  imposed  more  stringent  exit  criteria  for  each  phase.  Since  competitive 
prototyping  would  take  too  long  and  cost  significantly  more  money,  TPO  was  able  to  gain 
approval  for  a  competitive  award  to  one  system  contractor  for  DEMA^AL  and  all 
remaining  phases.  To  handle  the  risks  associated  with  single  source  procurement,  TPO 
funded  the  prime  contractor  to  dual  source  some  critical  items,  develop  others  in  parallel, 
and  maximize  competition  at  the  subcontractor  level. 
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V.  IMPACT  OF  THE  STRATEGY  AND  LESSONS-LEARNED 


A.  PURPOSE 

The  ultimate  evaluation  of  the  effectiveness  of  THAAD’s  acquisition  strategy  will 
take  place  when  the  system  first  faces  an  incoming  threat.  The  final  chapter  on  THAAD 
may  norte  written  for  many  years;  however,  based  on  early  results,  an  interim  assessment 
is  possible.  This  chapter  is  the  author’s  observations  of  the  tailored  acquisition  strategy’s 
impact  on  key  program  risks.  It  begins  by  citing  some  examples  of  what  has  occurred  in 
the  THAAD  UOES  program  as  a  result  of  the  TPO’s  tailoring  of  the  acquisition  strategy 
to  manage  key  risks.  From  these  observations  the  chapter  develops  acquisition 
management  lessons-leamed. 

B.  OBSERVED  IMPACTS  OF  THE  STRATEGY 

1.  System-Wide  Initiatives 
a.  Commonality 

LMSC  responded  to  TPO’s  stated  preference  for  conunercial-off-the-shelf 
(COTS)  items  by  incorporating  existing  DOD  equipment  wherever  possible.  Visible 
examples  of  common  items  are  the  PLS,  the  HMMWV,  and  the  SICPS.  Examples  that 
are  less  noticeable  include  THAAD’s  generators,  computers,  JTIDS  and  SINCGARS 
radios,  and  GPS  receivers.  LMSC’s  use  of  these  common  components  avoids  some 
technical  risk  because  these  subsystems  are  already  operational.  They  avoid 
supportability  risk  because  they  have  established  training  and  logistics  infrastructure.  For 
these  items,  there  is  practically  no  cost  and  schedule  risk  because  LMSC  can  order  them 
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from  the  vendor  for  an  established  catalog  price.  Use  of  common  items  helps  focus  the 
development  to  those  items  that  do  not  yet  exist.  With  this  more  accurate  view  of  the 
scope  of  the  program,  the  programmatic  decisions  can  be  confined  to  the  truly  new 
components. 

Use  of  common  items  presents  some  increased  technical  risk.  These  items 
were  not  specifically  designed  to  perform  a  TMD  function;  consequently,  THAAD’s 
design  engineers  have  to  work  within  the  limitations  of  the  common  items.  In  the  design 
process  there  is  a  trade-off  of  performance  (some  technical  risk  is  assumed)  to  gain  a 
decrease  in  cost,  schedule,  and  supportability  risks.  THAAD’s  designers  assessed  that  the 
performance  objectives  could  still  be  achieved  while  using  many  common  inventory 
items.  This  trade-off  resulted  in  an  overall  risk  reduction  for  the  program. 

b.  System  Integration  Laboratory 

System  integration  is  a  watchlist  item  that  TPO  assessed  as  a  moderate  risk 
at  MS  I.  LMSC,  prime  contractor  for  a  team  of  more  than  45  specialty  subcontractors, 
concurred  with  this  assessment.  In  response  to  TPO’s  requirement  for  a  risk  mitigation 
plan,  LMSC  developed  its  System  Integration  Laboratory  (SIL)  and  Missile  Simulation 
Laboratory.  These  two  faciUties  are  prime  examples  of  LMSC’s  exploitation  of  state-of- 
the-art  prototyping  methods  to  control  technical  risks  associated  with  interfacing  existing 
hardware  and  software  with  new  hardware  and  software. 

“The  SEL  provides  a  high  fidelity  test  lab  to  verify  THAAD  subsystem  and 
system  performance  in  a  realistic  and  programmable  combat  environment  [Ref.  16].” 
LMSC  and  many  of  its  subcontractors  use  rapid  component  prototyping  to  produce  a 
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design.  That  design  then  undergoes  hardware-in-the-loop  testing,  which  allows  a  variety 
of  testing  configurations.  The  physical  or  the  digital  product  may  be  combined  with  a 
prototype  of  new  or  revised  software  modules  to  test  the  impact  of  design  modifications 
in  a  virtual  or  semi-virtual  environment.  The  SIL  facilitates  integration  of  all  weapon 
system  hardware  and  software  elements. 

“The  Missile  Simulation  Laboratory  provides  the  high  fidelity  simulated 
flight  environment  necessary  for  dynamic  testing  of  missile  segment  components  from 
launch  through  intercept  [Ref.  16].”  This  lab  permits  real-time  virtual  operation  of  the 
KV’s  integrated  avionics  package.  These  operations  are  conducted  in  a  simulated  flight 
environment  that  closely  approximates  an  actual  in-flight  environment.  The  Missile 
Simulation  Lab  provides  a  means  to  develop,  test,  verify,  and  validate  software 
algorithms  used  by  an  in-flight  missile  and  its  KV. 

The  SIL  and  Missile  Simulation  Lab  are  valuable  prototyping  facilities  that 
enable  LMSC  and  its  large  team  of  subcontractors  to  efficiently  refine  a  component’s 
design  and  its  interfaces  with  minimal  schedule  and  cost  risk.  These  facilities  allow 
LMSC  to  conduct  almost  continuous  testing  of  every  hardware  and  software  component 
in  every  configuration  with  much  less  cost  and  schedule  impact  than  full  scale  testing. 

These  labs  enhance  the  value  of  data  collected  during  full  scale  testing. 
When  flight  test  three  did  not  meet  all  of  its  test  objectives,  LMSC  was  able  to  “replay” 
the  flight  test  data  in  the  lab.  This  enabled  software  and  design  engineers  to  trace  the 
performance  deficiency  to  its  root  cause,  thereby  helping  to  control  technical  risks. 
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2.  Impact  on  Subsystems 
a.  Interceptor 

As  part  of  its  risk  control  activities,  TPO  funded  numerous  preflight  tests 
on  various  missile  components  before  start  of  full  scale  flight  testing.  The  objective  of 
these  preflight  tests  was  to  control  technical,  cost,  and  schedule  risks  by  verifying  a 
component’s  compatibility  and  functionality  without  incurring  costs  associated  with 
actual  flight.  Preflight  tests  began  during  CD  and  still  take  place  after  each  significant 
hardware  or  software  change.  Several  static  firings  validated  the  booster’s  solid 
propellant  design  and  the  TVC  system’s  ability  to  steer  the  missile  during  boost  phase.  A 
series  of  "simulated  hot  launch  tests"  provided  missile  launch  verification  and 
demonstrated  proper  aerodynamic  flare  deployment.  LMSC  verified  the  DACS’s  ability 
to  steer  its  KV  in  a  typical  flight  scenario  through  hardware-in-the-loop  testing  with  all 
interceptor  subsystems  on-line.  [Ref.  16] 

Once  LMSC  verifies  a  component’s  compatibility  and  functionality,  it  is 
integrated  into  a  complete  missile  for  actual  flight  testing  at  White  Sands  Missile  Range. 
Original  DEMWAL  objectives  called  for  20  flight  tests.  The  flight  tests  started  with 
simple  test  objectives.  Each  subsequent  test  builds  on  previous  lessons-leamed  and 
demonstrates  revised  versions  of  software  and  hardware  as  they  mature. 

To  control  high  schedule  risk,  the  PM  obtained  Milestone  Decision 
Authority  permission  to  reduce  flight  tests  to  14  because  of  early  testing  success.  The 
original  preflight  and  the  flight  test  programs  allowed  for  some  re-testing,  if  necessary, 
with  redundant  test  objectives.  Once  LMSC  met  those  test  objectives  the  PM 
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recommended  restructuring  the  flight  test  program  to  eliminate  unnecessary  testing.  The 
PM’s  recommendation  was  a  trade-off  to  assume  some  moderate  technical  risk  in  order  to 
lower  the  program’s  high  schedule  risk. 

Hit-to-kill  technology  currently  borders  between  state-of-the-art  and 
cutting-edge.  LMSC  is  avoiding  some  technical  risks  by  building  THAAD  based  on 
experience  in  the  HEDI  and  KITE  experiments,  as  well  as  other  missile  defense 
demonstrations.  Designing  THAAD’ s  KV  is  technically  feasible  because  engineers  are 
essentially  repackaging  existing  hit-to-kill  technology  rather  than  completely  developing 
new  technology  [Ref.  15]. 

Production  of  KV  components  is  a  leading  example  of  LMSC’s  use  of 
rapid  prototyping  to  control  technical,  cost,  and  schedule  risks.  The  producibility  plan 
emphasizes  close  interaction  among  all  engineering  disciplines.  From  the  start  of 
conceptual  design,  producibility  engineers  have  continuous  access  to  the  designers’ 
database.  This  allows  for  producibility  analysis  concurrent  with  system  design.  When  a 
producibility  problem  arises,  design  engineers  take  corrective  action  before  they  waste 
resources  on  a  faulty  design.  For  example,  in  production  of  some  forecone  parts,  there 
was  a  paperless  transfer  of  the  design  to  numerically  controlled  machining  tools.  The 
subcontractor  for  the  shroud  that  covers  the  interstage  between  booster  and  KV  also  used 
rapid  prototyping  to  design  and  integrate  this  critical  component.  [Ref.  16] 

The  interceptor  is  the  subsystem  that  has  the  highest  technical  risk. 
Schedule  pressure  increased  this  risk  by  forcing  reliance  on  a  single  contractor  for 
DEMA^AL  and  all  remaining  phases.  To  control  this  risk  TPO  emphasized  teaming 


55 


arrangements  between  LMSC  and  subcontract  specialists.  The  SIL  and  the  Missile 
Simulation  lab  are  LMSC’s  response  to  the  need  for  an  efficient  method  to  integrate  the 
various  specialists’  components  to  produce  the  best  overall  technical  system. 

Considering  early  flight  test  success,  this  approach  of  integrating  teams  of  specialists  has 
helped  to  control  technical  risks.  This  reduction  in  interceptor  technical  risk  also  reduces 
the  cost  and  schedule  indicators  of  risk. 

b.  Ground  Based  Radar 

Major  risks  for  the  GBR  lie  in  its  extensive  use  of  software.  TMD-GBR  is 
reusing  about  300,000  lines  of  missile  defense-related  software  code  [Ref.  27:  p.  50]. 
BMDO  and  Advanced  Research  Projects  Agency  (ARP A)  developed  this  reusable  code 
during  previous  missile  defense  experiments.  This  code  is  a  starting  point  for  the  GBR 
prime  contractor,  Raytheon,  to  develop  a  series  of  evolutionary  software  prototype  builds. 
Raytheon  works  with  LMSC  in  the  SIL  to  integrate  these  software  prototypes  with  the 
other  subsystems  before  flight  testing.  After  a  flight  test  the  contractors  continue  to  refine 
the  software  prototype  based  on  its  effectiveness  to  meet  that  flight  test  objective. 
Software  reuse  and  evolutionary  software  prototyping  techniques  have  helped  control 
technical,  cost,  and  schedule  risks.  [Ref.  28:  p.  4-7] 

GBR’s  1992  operational  requirement  called  for  a  complete  radar  set  to  be 
transportable  on  five  C-130s.  [This  requirement  imposed  a  size  and  weight  limitation 
which  drove  the  use  of  solid-state  transmit  and  receive  (T/R)  modules  in  the  antenna.] 
Each  of  three  DEMA^AL  radar  antennas  contains  25,344  solid-state  T/R  modules,  and 
each  module  contains  nine  monolithic  microwave  integrated  circuit  chips  (MMIC).  The 
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technology  used  in  the  T/R  modules  was  not  itself  a  breakthrough;  however,  assembly  of 
over  75,000  miniature  modules  in  less  than  two  years  was  a  high  technical  risk.  To 
control  this  risk,  GBR’s  acquisition  strategy  required  the  prime  contractor  to  dual  source 
certain  high  risk  components.  Raytheon  produced  some  of  the  T/R  modules  and 
subcontracted  out  the  remaining  portion.  To  control  risk,  the  PM  closely  monitored 
production  of  T/R  modules  on  a  monthly  basis.  [Ref.  29:  p.  504] 

c.  BM/C3I 

The  BM/C3I  element,  like  the  KV  and  GBR,  is  a  software  intensive 
subsystem,  BM/C3I  software  differs  because  of  its  high  degree  of  human  interface. 
Software  for  the  KV  is  best  designed  with  input  from  physicists,  but  software  for  the 
BM/C3I  is  best  designed  with  input  from  soldier  operators.  The  subcontractor  for  the 
BM/C3I  element  is  Litton  Industries,  and  to  date  it  has  delivered  four  operational  BM/C3I 
shelters.  Two  units  are  used  to  support  DEM/VAL  flight  testing  at  White  Sands  Missile 
Range.  Two  more  units  are  used  to  verify  hardware  and  software  interfaces  in  the  SIL. 
Soldiers  assigned  to  the  first  THAAD  battery  have  almost  daily  access  to  the  systems  and 
are  currently  helping  design  engineers  evaluate  BM/C3I  operator  system  interfaces.  Their 
valuable  input  is  part  of  a  growing  human  factors  study  that  will  help  to  refine  suitability 
of  THAAD’ s  software  and  hardware.  [Ref.  21] 

Recent  LMSC  risk  assessment  reports  list  software  as  having  high 
technical,  cost,  and  schedule  risks.  To  control  these  risks  Litton  also  relies  on 
evolutionary  software  prototyping  techmques.  Current  plans  call  for  seven  major 
incremental  software  builds  to  achieve  full  functionality  in  the  objective  system.  The 
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UOES  version  will  use  the  third  major  build,  which  designers  expect  will  contain  372,000 
lines  of  Ada  code.  This  is  about  half  of  what  the  objective  system  will  require  [Ref.  27: 
p.  50].  To  control  schedule  risk,  TPO  has  at  times  removed  or  deferred  some  functions 
from  incremental  software  builds. 

Litton  controls  hardware  technical  and  supportability  risks  by  closely 
monitoring  throughput  and  memory  utilization.  To  control  high  schedule  risk  for  UOES 
development,  TPO  made  some  risk  trade-offs  in  areas  of  the  program  that  would  require 
more  time  to  resolve  than  was  available.  For  example,  TPO  was  able  to  gain  a  waiver  for 
the  requirement  for  electromagnetic  pulse  (EMP)  hardening  of  the  system.  LMSC  is 
required  to  resolve  these  issues  as  part  of  a  larger  “Growth  to  Objective  System”  plan. 
LMSC  and  Litton  are  conducting  ongoing  trade  studies  to  define  the  optimum  hardware 
design  for  the  objective  system.  [Ref.  15] 

Many  external  interface  requirements  stem  from  BMDO’s  goal  to 
coordinate  all  missile  defense  BM/C3I  issues.  This  goal  has  increased  technical  and 
programmatic  risks  for  THAAD.  For  example,  the  JTIDS  radio  is  an  externally  driven 
hardware  requirement.  This  radio  lacks  adequate  throughput  for  THAAD  to  mature  to 
full  objective  system  capability.  TPO  projects  that  the  objective  system  will  need 
communications  throughput  capability  of  one  megabit  of  information  in  half  a  second  or 
less.  TPO  is  currently  staffing  a  request  to  replace  JTIDS  with  the  Secure  Packet  Radio 
(SPR)  because  it  is  the  only  radio  on  the  market  that  can  provide  adequate  throughput 
capability.  [Ref.  30] 
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3.  Programmatic  Risk 

Programmatic  risk  has  fluctuated  widely,  primarily  as  a  function  of  political 
support  and  perceived  threat.  Since  January  1992,  when  THAAD’s  acquisition  strategy 
was  formally  approved,  there  have  been  some  significant  external  events  that  have 
affected  the  program.  These  external  events  center  around  three  interrelated  issues: 

(1)  the  diplomatic  regulation  of  some  of  the  THAAD  system’s  features  under  the  Anti- 
Ballistic  Missile  Treaty,  (2)  the  political  maneuvering  around  the  definition  of  the 
ballistic  missile  threat,  and  (3)  the  Federal  Budget  crisis.  These  three  issues  have 
resulted  in  much  more  scrutiny  of  the  THAAD  program  than  was  expected  back  in  1990 
and  1991  when  the  UOES  approach  was  adopted. 

There  are  clear  political  lines  drawn  over  the  validity  of  the  Anti-Ballistic  Missile 
Treaty.  One  side  of  this  issue  stresses  that  the  Soviet  Union  no  longer  exists  and  the 
United  States  missile  defense  programs,  including  THAAD,  should  not  be  constrained  by 
an  outdated  agreement.  This  side  of  the  argument  also  emphasizes  that  the  talented 
personnel  that  built  the  former  Soviet  Union’s  ballistic  missile  arsenal  have  dispersed  to 
many  rogue  nations  around  the  world.  The  other  side  of  this  issue  stresses  that  much  of 
the  former  Soviet  Union’s  nuclear  arsenal  still  exists  and  so  the  Anti-Ballistic  Missile 
Treaty  should  remain  in  effect,  constraining  THAAD  development.  Under  this  thinking, 
the  most  effective  method  to  reduce  the  threat  is  through  diligent  diplomatic  negotiations 
with  the  new  nations  who  possess  renmants  of  the  Soviet  arsenal. 

As  mentioned  in  Chapter  I,  the  Clinton  administration  has  downgraded  the  NMD 
program  to  a  Technology  Readiness  Program.  Until  June  1995,  the  GBR  was  a  separate 
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NMD  project  office  that  would  provide  the  THAAD  program  with  two  radars  as  GFE. 
This  was  a  practical  approach  given  the  similar  functions  and  design  shared  between  the 
TMD  and  the  NMD  versions  of  the  radar.  In  1994  when  the  Clinton  Administration 
downgraded  NMD  to  a  Technology  Readiness  Program,  TPO  began  to  assume  most  of 
the  $492.2  million  responsibility  for  development  of  its  own  radar  [Ref.  31:  p.  89].  Since 
June  1995,  GBR  has  been  a  product  office  within  the  TPO. 

This  project  office  merger  was  a  programmatic  risk  for  the  program  in  that  it 
meant  increased  development  responsibility  for  TPO.  GBR  was  also  in  DEMA^AL,  but 
its  acquisition  strategy  called  for  a  competitive  selection  for  the  EMD  contract.  Raytheon 
was  not  under  contract  to  develop  an  objective  system;  its  focus  was  only  to  deliver  three 
DEMA^AL  operational  prototypes,  which  would  consist  of  one  NMD  version  and  two 
TMD  versions.  TPO  had  to  modify  Raytheon’s  contract  to  include  concurrent  work  on  an 
objective  system.  For  the  remainder  of  DEMA^AL  Raytheon  and  LMSC  have  an 
associate  contract  relationship.  This  new  arrangement  required  the  two  contractors  to 
exchange  technical  information,  as  needed,  based  on  an  information  exchange  agreement. 

There  are  political  lines  drawn  around  the  issue  of  ballistic  missile  threat.  One 
side  of  the  debate  emphasizes  the  intelligence  assessments  that  a  threat  to  the  United 
States  already  exists,  or  it  will  exist  in  less  than  five  years.  The  other  side  of  the  debate 
emphasizes  that  some  intelligence  estimates  indicate  that  a  ballistic  missile  threat  is  not  a 
significant  concern  for  15  or  more  years.  This  continuing  debate  creates  uncertainties 
about  the  future  of  the  THAAD’s  objective  system. 
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Programmatic  risks,  as  evidenced  by  changing  policy,  continue  to  be  high.  For 
example,  from  November  1995  until  February  1996  DOD  conducted  a  complete  review 
of  all  missile  defense  programs.  In  mid-November  PEO  for  Missile  Defense 
recommended  a  two  year  acceleration  of  the  objective  system  [Ref.  32:  p.  4].  By  early 
January  this  proposal  became  known  as  the  “THAAD  lite,”  which  would  be  a  reduced 
capability  objective  system  [Ref  33:  p.  3].  However,  the  SEC  DEF  had  a  news 
conference  on  February  16, 1996  to  announce  changes  as  a  result  of  the  missile  defense 
review.  The  result  was  significantly  different  from  the  PEO’s  reconunendation.  In  that 
conference  the  SEC  DEF  announced: 

•  The  objective  system  will  lose  about  $2  billion  out  of  what  was  a  $5  billion 
program  through  the  future  years  defense  plan  (FYDP). 

•  The  objective  system  will  be  delayed. 

•  The  UOES  will  be  enhanced  with  some  seeker  and  radar  improvements. 

•  In  two  years,  after  Navy  Upper-Tier  completes  CD  phase,  it  will 
consider  a  marinized  version  of  THAAD’ s  missile  to  use  on  the  Aegis 
missile  defense  platform.  [Ref.  34:  p.  6] 

All  of  this  political  and  diplomatic  maneuvering  leads  to  high  programmatic  risk 
for  UOES  and  the  objective  system.  In  the  short  term,  for  UOES,  the  additional 
development  responsibility  increased  technical,  supportability,  schedule,  and  costs  risks. 
In  the  long  term,  development  and  delivery  of  the  full  objective  system  is  at  risk.  Early 
successes  within  the  UOES  portion  of  the  program  fostered  a  perception  that  perhaps 
some  of  the  funding  for  the  objective  system  was  unnecessary  or  that  it  could  be  deferred 
with  little  consequence.  Progranunatic  risks  are  inherently  unpredictable,  and  many  of 
THAAD’ s  other  types  of  risk  are  traceable  to  external  requirements  that  are  beyond 
TPO’s  span  of  control. 
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4.  Cost  And  Schedule  Growth 


As  typical  of  most  programs,  THAAD  has  experienced  both  cost  and  schedule 
growth.  Chapter  n  indicated  some  expected  cost  and  schedule  outcomes  for  programs 
that  make  extensive  use  of  prototypes  (Figures  3  and  4  as  well  as  Table  2). 

As  of  March  1996,  the  DEMA^AL  contract  estimate  at  completion  is 
approximately  $1.2  billion  (this  figure  includes  the  DOES  option  and  the  five  years  of 
maintenance  that  will  be  added  to  the  EMD  contract)[Ref.  35].  The  program  is  primarily 
event  driven,  but  it  is  about  12  months  behind  the  original  schedule  [Ref.  35].  It  is  still 
too  early  in  the  program  and  beyond  the  scope  of  this  thesis  to  determine  exactly  what 
portion  of  the  cost  and  schedule  growth  is  attributable  to  what  types  of  risk.  However, 
based  on  observation  of  the  contractor’s  response  to  the  strategy  and  events  that  have 
occurred  since  MS  I,  an  interim  assessment  of  cost  and  schedule  follows. 

The  CPFF  contract  DEMA^AL  including  the  UOES  option  was  based  on  a  total 
price  of  $923.8  million.  The  current  estimate  at  completion  is  $1.2  billion,  so  it  appears 
that  there  is  about  $276  million  in  cost  growth.  However,  the  largest  portion  of  this  cost 
growth  is  traceable  to  the  increased  scope  of  work  related  to  development  of  the  GBR. 
Both  the  LMSC  and  Raytheon  contracts  have  thus  had  major  modifications,  and  resolving 
these  modifications  is  an  ongoing  issue.  Estimates  indicate  that  the  additional  cost 
traceable  to  GBR  will  exceed  $200  million.  Another  increased  scope  of  work  is  related  to 
electromagnetic  pulse  hardening  of  the  UOES  equipment.  This  additional  requirement 
will  add  several  million  dollars  to  THAAD’ s  development  cost.  This  requirement  is  a 
result  of  recent  considerations  to  use  the  UOES  system  longer  than  its  planned  five  year 


62 


life.  The  UOES  equipment  does  not  contain  many  of  the  features  of  the  objective  system, 
and  therefore  additional  requirements  lead  to  high  supportability  and  cost  risks. 

Initial  assessments  of  THAAD’s  schedule  as  “aggressive”  have  proven  to  be 
accurate.  The  twelve  month  schedule  growth  is  almost  solely  attributable  to  software 
issues  among  the  interceptor,  GBR,  and  BM/C3I  elements.  The  contractors  continue  to 
employ  teams  of  specialists  in  this  critical  program  area  and  rely  on  proven  methods,  but 
schedule  risk  is  usually  very  high  for  complex  software  [Ref.  36:  p.  52]. 

C.  LESSONS-LEARNED 

The  following  list  of  lessons-leamed  come  from  the  author’s  observations  of  what 
has  occurred  thus  far  in  the  THAAD  program.  This  list  is  an  overall  interim  assessment 
of  the  acquisition  strategy  based  on  events  and  actions  from  the  first  statement  of  need  in 
1988  until  March  1996. 

•  Use  of  common  existing  inventory  items  as  subsystems  helps  avoid  some 
technical  risk.  Because  those  subsystems  are  already  operationally  effective  and 
suitable  systems,  they  help  avoid  supportability  risk  with  an  established  training  and 
logistics  infrastructure.  For  these  items,  there  is  very  little  cost  and  schedule  risk 
because  the  items  may  be  provided  as  GFE  or  separately  purchased  from  a  vendor. 
Use  of  common  items  helps  isolate  the  scope  of  the  development  to  those  functions 
that  do  not  yet  exist. 


•  Use  of  common  existing  inventory  items  can  also  increase  technical  risk.  Existing 
inventory  items  are,  by  definition,  not  specifically  designed  to  perform  THAAD’s 
TBM  function.  Design  engineers  had  to  work  within  limitations  of  the  existing 
system’s  capability  and  assumed  some  technical  risk  in  a  trade-off  for  lower  cost, 
schedule,  and  supportability  risk. 
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•  Funding  a  contractor  for  a  system  integration  initiative  can  help  maximize  the 
benefits  from  component,  software,  and  virtual  prototyping  methods.  This  can 
help  control  schedule  and  cost  risk  through  virtual  or  semi-virtual  testing  to  avoid 
commitment  to  a  testing  program  until  interface  of  the  hardware  and  software 
components  can  be  established.  An  integration  facility  can  help  control  technical  risk 
by  efficiently  optimizing  an  overall  system  design.  It  can  increase  the  value  of  actual 
testing  by  providing  the  means  to  conduct  in-depth  analysis  of  actual  test  data  to  help 
identify  a  root  cause  of  a  performance  deficiency. 


•  Software  technical  risks  can  be  partially  controlled  by  reusing  the  existing 
software  of  systems  that  have  simUar  functions.  For  THAAD,  reused  software 
became  a  starting  point  for  a  series  of  evolutionary  software  prototype  builds,  which 
helped  to  control  technical,  schedule,  and  cost  risks. 


•  Rapid  prototyping,  combined  with  hardware>in-the<loop  testing,  enables  a 
variety  of  design  configurations  with  minimal  cost  and  schedule  risk.  Use  of 
rapid  prototyping  methods  helped  control  technical  risks  by  allowing  technical 
designers  to  communicate  their  design  more  efficiently  to  non-technical  audiences.  In 
THAAD,  rapid  prototyping  is  credited  for  helping  to  control  technical  and  schedule 
risk  by  providing  for  a  paperless  transfer  from  design  equipment  to  numerically 
controlled  machining  tools. 


•  Test  objectives  should  be  incremental,  allow  for  integration  of  revised  versions  of 
hardware  and  software,  and  take  advantage  of  simulation  in  testing.  A  thorough 
preflight  test  program  enabled  TPO  to  verify  hardware  and  software  components’ 
compatibility  and  functionality  after  each  significant  configuration  change  and  before 
start  of  full  scale  testing.  TPO  used  the  preflight  test  to  control  technical,  schedule, 
and  cost  risks.  When  LMSC  accomplished  some  test  objectives  early,  TPO  was  able 
to  partially  control  high  schedule  risk  by  assuming  moderate  technical  risk. 


•  Reconfiguration  and  refinement  of  existing  technologies  can  help  to  control 
technical  and  schedule  risks.  Rather  than  completely  developing  new  technology, 
TPO  required  the  prime  contractor  to  avoid  some  technical  risks  by  building  THAAD 
based  on  proof  of  concept  that  occurred  in  previous  missile  defense  experiments. 
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•  Programs  on  very  aggressive  schedules  often  have  to  make  concessions  in  some 
functional  areas  to  achieve  the  schedule  requirement.  TPO  recognized  early  that 
there  was  not  sufficient  time  to  establish  and  refine  a  logistics  support  plan  for  the 
UOES.  Before  MS  I  TPO  conceded  that  the  contractor  would  have  to  provide  this 
function.  To  control  technical  and  supportability  risks  associated  with  this 
operational  concession,  TPO  required  the  prime  contractor  to  develop  and  maintain  a 
Growth  to  Objective  System  plan,  which  established  clear  paths  of  development  from 
UOES  to  the  objective  system. 


•  If  a  program  must  rely  on  a  single  source  for  development  and  production,  the 
PM  should  take  significant  precautionary  measures  to  control  the  risk  associated 
with  sole  source  procurement.  TPO  emphasized  teaming  arrangements,  and  LMSC 
is  essentially  the  program  integrator  for  a  team  of  45  specialists.  To  control  risk  TPO 
funded  LMSC  to  develop  a  risk  mitigation  plan,  which  includes  the  SIL  and  the 
Missile  Simulation  Lab.  Other  precautionary  measures  included:  dual  sourcing 
certain  high  risk  components;  developing  parallel  designs  until  the  best  one  is 
identified;  and  funding  trade  studies  in  high  risk  functions  to  identify  an  optimal 
design. 


•  Programmatic  risk  receives  too  little  consideration  during  risk  management 
planning.  Strong  political  support  initially  gave  the  legislative  mandate  that  resulted 
in  a  UOES  operational  prototype  strategy.  Four  years  later,  decreased  political 
support  resulted  in  increased  programmatic  risk.  Now  the  objective  system  may  not 
be  fielded  until  much  later  than  originally  planned,  or  the  objective  system  may  have 
much  less  performance  capability  than  originally  planned.  The  recent  DOD-wide 
missile  defense  review  announcement  confirms  one  of  the  disadvantages  of 
prototyping  in  that  it  delays  a  full  funding  commitment.  Programmatic  risk  associated 
with  the  NMD  program  resulted  in  increased  technical,  supportability,  schedule,  and 
cost  risks  for  UOES.  The  GBR  is  now  back  on  track  and  keeping  pace  with 
TELAAD’s  schedule,  but  in  1994  and  1995  the  outcome  was  uncertain. 
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VI.  CONCLUSION  AND  RECOMMENDATIONS 


A.  SUMMARY 

This  thesis  is  an  early  examination  of  the  THAAD  program’s  implementation  of 
the  User  Operational  Evaluation  System  acquisition  strategy.  It  developed  a  framework 
for  analysis  of  UOES  risk  management  issues  using  DOD  risk  management  guidance. 
This  framework  incorporates  some  current  methods,  applications,  and  trends  in  the  roles 
prototypes  play  during  development.  Using  that  framework,  it  analyzes  the  observed 
impact  of  THAAD’ s  tailored  acquisition  strategy  on  the  program  thus  far.  From  these 
observations  it  listed  lessons  that  have  been  learned  from  the  program’s  experience,  and 
the  author  offers  the  following  general  conclusions  and  recommendations. 

B.  CONCLUSIONS 

•  The  User  Operational  Evaluation  System  acquisition  strategy  is  a  special 
response  to  a  unique  situation. 

An  analysis  of  the  situation  that  resulted  in  the  UOES  approach  supports  this 
conclusion.  The  BMDO  planners  had  to  tailor  an  acquisition  strategy  to  meet  the  1991 
legislative  mandate  for  “an  operationally  effective  TMD  capability  by  1996."  This 
mandate  was  a  result  of  a  growing  political  concern  for  ballistic  missile  defense  at  home 
and  for  forward  deployed  U.S.  forces.  This  unique  and  urgent  mandate  combined  with 
restrictions  imposed  by  the  Anti-Ballistic  Missile  treaty  limited  the  range  of  options 
available.  A  traditional  acquisition  strategy  could  not  produce  a  fieldable  system  until 
several  years  beyond  1996.  A  UOES  approach  would  be  much  faster  because  it  would 
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rapidly  develop  only  core  capabilities.  The  strategy  is  based  on  the  premise  that  schedule 
risk  was  decreased  for  UOES  because  it  does  not  include  final  plans  for  logistics, 
training,  and  full  operational  capability  of  the  objective  system. 

•  An  operational  prototype  strategy  shifts  much  of  the  technical  and 
supportability  risks  related  to  operational  requirements  forward 
in  the  acquisition  cycle. 

An  example  of  this  is  that  design  specifications  were  part  of  the  DEMA^AL 
competitive  proposal  process.  Typically,  no  more  than  system  specifications  are  required 
at  the  end  of  CD.  This  accelerated  requirement  increased  technical  and  supportability  risk 
by  requiring  designers  to  commit  to  a  particular  design  much  earlier  in  the  acquisition 
cycle  than  this  critical  step  usually  occurs.  Another  example  is  that  the  system  has  to 
achieve  a  limited  operational  capability  before  MS  n.  To  partially  offset  this  increased 
risk,  the  TPO  has  required  parallel  development  of  some  critical  components  to  allow  for 
a  ready  alternative  if  the  primary  design  is  not  technically  feasible  or  supportable.  Both 
of  these  requirements  resulted  in  increased  development  schedule  and  costs. 

•  An  operational  prototype  strategy  increases  programmatic  risk  by 
creating  an  alternative  to  commitment  to  full  objective  system 
funding. 

This  conclusion  is  consistent  with  the  findings  discussed  in  Chapter  11,  and  for 
THAAD  this  conclusion  is  evident  from  the  programmatic  events  that  have  occurred 
since  1991.  BMDO  planners  did  not  adequately  consider  long-term  programmatic  risk 
when  they  adopted  the  UOES  approach.  Long-term  success  hinged  on  a  limited  UOES 
capability  to  temporarily  meet  the  requirement,  while  designers  would  use  experience 
gained  from  its  operation  to  help  develop  a  more  robust  objective  system.  Now,  five 
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years  after  selection  of  the  UOES  approach  it  appears  the  UOES  is  going  to  be  kept 
longer,  and  the  scope  of  that  portion  of  the  program  will  be  enlarged  at  the  expense  of  the 
objective  system. 

•  DOD’s  Advanced  Concept  Technology  Demonstration  now 
addresses  many  of  the  same  objectives  that  the  UOES  attempted  to 
achieve. 

^oth  approaches  have  overlapping  goals  in  that;  (1)  user  experience  gained  from 
operating  the  system  is  used  to  help  refine  a  more  suitable  final  product,  (2)  if  needed,  the 
system  is  available  for  a  contingency  mission. 

C.  AREAS  FOR  FURTHER  STUDY 

In  the  course  of  this  thesis  research,  the  author  identified  several  promising  areas 
for  future  research. 

•  Determine  how  THAAD’s  cost  and  schedule  performance  compare 
to  the  cost  and  schedule  performance  of  other  programs  that  did 
or  did  not  prototype. 

THAAD  has  experienced  cost  and  schedule  growth.  A  study  should  be  conducted 
when  the  program  completes  DEMA^AL,  which  is  now  projected  for  1997.  This  study 
should  first  define  if  UOES,  with  its  contractor-provided  maintenance  concept,  can  be 
realistically  compared  with  other  systems  that  use  the  traditional  definition  of  IOC.  The 
study  could  determine  what  portion  of  the  cost  and  schedule  growth  is  attributable  to 
increased  requirements,  inaccurate  estimates,  and  from  programmatic  changes.  The  study 
could  reconomend  improvements  to  UOES  and  ACTD  acquisition  approaches  to  help 
better  control  cost  and  schedule  risks. 
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•  Determine  the  effectiveness  of  operational  prototypes  to  influence 
the  objective  system’s  design. 

A  starting  point  might  be  to  analyze  how  these  acquisition  strategies  actually 
impacted  mission  effectiveness  to  determine: 

•  What  are  the  additional  risks  associated  with  fielding  a  less  than 
mature  system? 

•  What  are  the  recommended  management  structures  used  to  control 
these  types  of  programs? 

•  What  is  an  effective  method  for  collecting  and  implementing  user 
suggestions? 


•  Investigate  software  reuse  across  missile  defense  programs. 

In  THAAD,  the  GBR  and  the  BM/C3I  reused  a  significant  portion  of  existing 
software  code.  This  investigation  could  include: 

•  a  comparison  of  other  organization’s  reuse  policy  to  BMDO’s  reuse 
policy. 

•  a  comparison  of  the  architectures  other  real-time  information  systems. 

•  a  recommendation  for  policies  concerning  missile  defense  software 
architecture. 


•  Study  how  to  maintain  a  standardized  communication 
architecture  in  the  rapidly  expanding  demand  for  frequency 
bandwidth. 

THAAD  objective  system  will  require  more  throughput  than  the  current  standard 
Joint  Tactical  Information  Distribution  System  can  provide.  This  study  could  include: 

•  a  review  of  current  and  projected  DOD  needs. 

•  a  review  of  the  projected  technological  break-throughs  that  DOD 
communications  planners  should  be  prepared  for. 

•  a  recommendation  for  how  to  efficiently  take  advantage  of 
technological  innovation. 
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APPENDIX  A.  DEFINITIONS  AND  ACRONYMS 


DEFINITIONS 

Advanced  Concept  Technology  Demonstration  -  an  integrating  effort  to  assemble  and 
demonstrate  a  significant,  new  military  capability,  based  upon  maturing  advanced 
technology (s),  in  a  real-time  operational  environment  at  a  scale  adequate  to  clearly 
establish  operational  utility  and  system  integrity.  The  purpose  of  an  ACTD  is  to  address 
problems  in  acquisition,  system  development  and  product  transition.  The  ACTD 
approach  is  designed  to  transfer  mature  technologies  rapidly  from  the  developers  to  the 
users[Ref.  1 1 :  p.5].  An  ACTD  is  not  an  acquisition  program,  has  no  firm  operational 
requirements,  nor  a  firm  Contingency  Operations  Plan  (CONORS)  [Ref.  37:  p.  7]. 

design  -  (verb)  to  make  preliminary  sketches  of,  a  sketch  a  pattern,  or  outline  for. 

-  (noun)  a  plan;  a  thing  planned  for  or  outcome  aimed  at.  [Ref.  38:  p.  373] 

effectiveness  -  the  performance  or  output  received  from  an  approach  or  a  program. 
Ideally,  it  is  a  quantitative  measure  which  can  be  used  to  evaluate  the  level  of 
performance  in  relation  to  some  standard,  set  of  criteria,  or  objective  [Ref.  39:  p.  B-4]. 

evaluation  -  the  process  whereby  data  are  logically  assembled  and  analyzed  to  aid  in 
making  systematic  decisions  [Ref.  39:  14-1]. 

external  forces  -  program  factors  that  lie  outside  a  PM’s  span  of  control,  although  a  PM 
may  have  some  limited  influence  over  these  factors.  Examples  include  events, 
technologies,  funding  support,  or  user  requirements  that  are  critical  to  a  program’s 
success  and  influence  its  direction. 

internal  forces  -  any  program  factor  that  a  PM  can  directly  control. 

leverage  -  to  increase  the  means  of  accomplishing  some  purpose,  largely  through  the  use 
of  borrowed  ideas  or  technologies. 

operational  prototype  -  a  prototype  that  can  deliver  some  degree  of  useful  military 
capability,  but  a  capability  that  is  less  than  the  full  operational  capability  that  is  required 
in  the  system’s  Operational  Requirement  Document  [Ref.  37:  p.  7]. 

system  -  a  composite,  at  any  level  of  complexity,  of  personnel,  procedures,  materials, 
tools,  equipment,  facilities,  and  software.  The  elements  of  this  composite  entity  are  used 
together  in  the  intended  operational  or  support  environment  to  perform  a  given  task  or 
achieve  a  specified  production,  support  or  mission  requirement  [Ref.  39:  B-12]. 
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User  Operational  Evaluation  System  -  an  operational  feature  of  a  program’s  acquisition 
strategy  that  provides  for  early  user  involvement  to  influence  the  objective  system  design 
and  may  provide  for  the  war-fighter  a  military  useful  interim  contingency  option.  A 
UOES  is  not  an  ACTD.  A  UOES  is  embedded  within  an  approved  acquisition  program. 
The  approved  acquisition  program  is  based  on  firm  operational  and  developmental 
requirements  as  well  as  an  approved  Contingency  Operation  Plan  (CONOPS)  [Ref.  37:  p. 
7]. 

user  -  the  user  is  generally  regarded  as  the  combat  or  operator  community  for  which  the 
system  is  being  acquired.  The  ultimate  user  is  the  regional  war-fighting  Commander’s  in 
Chief  (eNCs)  [Ref.  37:  p.  8] 


ACRONYM 

ABM 

ACAT 

ACTD 

ADM 

ARPA 

ATD 

BM/C3I 

BMDO 

CAD 

CASE 

CD 

CE/D 

CONOP 

COSTAR 

COTS 

CPR 

CRC 

CWBS 

DACS 

DEMA^AL 

DOD 

DSMC 

EMD 

ERIS 

FFP 

nsT 

FPTOC 

FTV 

GBR 


FULL  TITLE 

anti-ballistic  missile 
Acquisition  Category 

Advanced  Concept  Technology  Demonstration 
Acquisition  Decision  Memorandum 
Advanced  Research  Projects  Agency 
Advanced  Technology  Demonstration 
Battle  Management/Command,  Control,  Communications,  and 
Intelligence 

Ballistic  Missile  Defense  Organization 

computer  aided  design 

computer  aided  software  engineering 

Concept  Definition 

Concept  Exploration  &  Definition 

Contingency  Operations  Plan 

corrective  optics  space  telescope  axial  replacement 

commercial  off  the  shelf 

Cost  Performance 

communication  reporting  center 

Contractor  Work  Breakdown  Structure 

divert  and  attitude  control  system 

Demonstration  and  Validation 

Department  of  Defense 

Defense  Systems  Management  College 

Engineering  and  Manufacturing  Development 

Exoatmospheric  Reentry  Vehicle  Interceptor  Subsystem 

Firm  Fixed  Price 

Flight  Projects  Office  Information  Systems  Testbed 
Force  Protection  Tactical  Operations  Center 
flight  test  vehicle 
Ground  Based  Radar 
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GFE 

GPS 

HAWK 

HEDI 

HMMWV 

HOE 

HST 

HWIL 

ICBM 

IDA 

ILSP 

IOC 

IR 

JPL 

JROC 

JTAGS 

JTIDS 

JTMD 

KITE 

KV 

LMSC 

LRIP 

MDA 

MEADS 

MFP 

MMIC 

MNS 

MS 

NASA 

NMD 

NMD-GBR 

ORD 

PATRIOT 

PATRIOT  PAC-2 

PATRIOT  PAC-3 

PEO 

PLS 

PM 

RDT&E 

RFP 

RISC 

SDC 

SDIO 

SECDEF 


Government  Furnished  Equipment 

Global  Positioning  System 

Homing  All  Weather  Killer 

High  Endoatmospheric  Defense  Interceptor 

High  Mobility  Multi-purpose  Wheeled  Vehicle 

Homing  Overlay  Experiment 

Hubble  Space  Telescope 

hardware-in-the-loop 

inter-continental  ballistic  missile 

Institute  for  Defense  Analysis 

Integrated  Logistics  Support  Plan 

initial  operational  capability 

infrared 

Jet  Propulsion  Laboratory 
Joint  Requirements  Oversight  Counsel 
Joint  Tactical  Ground  Station 
Joint  Tactical  Information  Distribution  System 
Joint  Theater  Missile  Defense 
Kinetic  Kill  Vehicle  Integrated  Technology  Experiment 
kill  vehicle 

Lockheed  Missiles  and  Space  Company 
low  rate  initial  production 
milestone  decision  authority 
Medium  Extended-range  Air  Defense  System 
Material  Fielding  Plan 

monolithic  microwave  integrated  circuit  chips 

Mission  Need  Statement 

Milestone 

National  Aeronautics  and  Space  Administration 

National  Missile  Defense 

National  Missile  Defense  Ground  Based  Radar 

operational  requirements  document 

phased-array  tracking  to  intercept  of  target 

PATRIOT  Advanced  Capability-2 

PATRIOT  Advanced  Capability-3 

program  executive  office 

Palletized  Load  System 

project  or  program  manager 

research,  development,  test  and  evaluation 

Request  for  Proposal 

reduced  instruction-set  computing 

Strategic  Defense  Command 

Strategic  Defense  Initiative  Organization 

Secretary  of  Defense 
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SICPS 

Steindard  Integrated  Command  Post  Shelter 

SIL 

System  Integration  Lab 

SINCGARS 

Single  Channel  Ground  and  Airborne  Radio  System 

SLA 

stereolithography 

SPR 

Secure  Packet  Radio 

SSA 

source  selection  authority 

SSEB 

source  selection  evaluation  board 

TBM 

tactical  ballistic  missile 

THAAD 

theater  high  altitude  area  defense 

TMD 

theater  missile  defense 

TMD-GBR 

theater  missile  defense  ground  based  radar 

TOC 

tactical  operations  center 

TPO 

THAAD  Project  Office 

T/R 

transmit  and  receive 

TVC 

thrust  vector  control 

UAV 

unmanned  aerial  vehicle 

UOES 

user  operational  evaluation  system 

USD  (A&T) 

Under  Secretary  of  Defense  for  Acquisition  and  Technology 

USMC 

United  States  Marine  Corps 
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APPENDIX  B.  RISK  MANAGEMENT  TERMINOLOGY 


Chapter  11’ s  outline  of  Risk  Management  in  DOD  is  based  on  DSMC’s  1989  Risk 
Management  Guide;  THAAD’s  acquisition  strategy  was  approved  in  1992;  and  the  DOD 
Regulation  5000.2  was  updated  in  1996.  Each  document  uses  slightly  different  risk 
management  terms.  This  table  summarizes  the  terms  used,  and  for  the  objective  of  this 
thesis,  the  one  relevant  difference  is  shaded. 


DSMC  RISK 
MANAGEMENT  GUfflE 

1989 

THAAD  ACQUISITION 
STRATEGY 

1992 

NEW 

DOD-R  5000.2 

1996 

FACETS  OF  RISK 

Technical 

Technical 

Performance 

Programmatic 

Programmatic 

Supportability 

Cost 

Cost 

Cost 

Schedule 

Schedule 

Schedule 

RISK  MANAGEMENT  STRUCTURE 

Planning 

Planning 

Planning 

Assessment 

Assessment 

Assessment 

Analysis 

Analysis 

Analysis 

Handling 

•  Avoidance 

•  Control 

•  Assumption 

•  Transfer 

MM 

The  most  important  difference  is  the  shift  in  risk  handling  activities.  The  new 
term  for  risk  handling  is  “risk  reduction,”  which  is  accomplished  through  “risk 
mitigation.”  Risk  mitigation  is  a  broad  term  that  may  include  any  of  the  previous 
techniques  of  avoidance,  control,  assumption,  and  transfer. 

Each  of  these  three  documents  serves  a  different  purpose.  DSMC’s  1989 
document  is  a  comprehensive  “Risk  Management  Guide”  and  it  contains  the  most  detail. 
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The  1996  DOD-R  5000.2  is  another  comprehensive  document,  but  its  sole  purpose  is  not 
risk  management,  and  it  naturally  will  not  contain  as  much  risk  management  detail. 
THAAD’s  acquisition  strategy  is  of  course  only  concerned  with  risk  management  in  the 
THAAD  program. 
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